[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7e6607bb-221f-462f-ba61-2a72a917bc81@gmail.com>
Date: Sun, 3 Aug 2025 00:06:27 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: oss-security@...ts.openwall.com, Solar Designer <solar@...nwall.com>
Cc: Van1sh <van1sh@...me>, Willy Tarreau <w@....eu>
Subject: Re: Linux kernel: eBPF vulnerabilities
On 8/2/25 21:55, Solar Designer wrote:
> Hi,
>
> Van1sh, CC'ed here, brought a set of 11 Linux kernel eBPF subsystem
> vulnerabilities to the kernel security team and linux-distros at once on
> July 19. Such early notification to linux-distros of issues not yet
> handled by the kernel security team is currently (and has been for a
> while) against guidelines from both the kernel and linux-distros:
>
> https://docs.kernel.org/process/security-bugs.html
>
>> the kernel security team strongly recommends that as a reporter
>> of a potential security issue you DO NOT contact the "linux-distros"
>> mailing list UNTIL a fix is accepted by the affected code's maintainers
>> and you have read the distros wiki page above and you fully understand
>> the requirements that contacting "linux-distros" will impose on you and
>> the kernel community. This also means that in general it doesn't make
>> sense to Cc: both lists at once, except maybe for coordination if and
>> while an accepted fix has not yet been merged. In other words, until a
>> fix is accepted do not Cc: "linux-distros", and after it's merged do not
>> Cc: the kernel security team.
>
> https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-reporters
>
>> For Linux kernel issues, you must notify the kernel security team
>> first, wait for the fix, and only then notify linux-distros or
>> oss-security (depending on whether the information is still private or
>> already public, as well as on issue severity).
>>
>> The maximum acceptable embargo period for issues disclosed to these
>> lists is 14 days.
>
> Van1sh also seemed to suggest a 28-day embargo period.
>
> So we immediately had a problem with the process. Luckily, Van1sh's
> message that reached linux-distros didn't actually contain what it calls
> "Disclosure Package". So only high-level summaries were included, not
> vulnerability detail. This is also what I am disclosing publicly here
> on oss-security today, as we're just past the 14 days maximum now.
>
> There was a little bit of discussion on linux-distros, and the most
> important aspect is that distros and systems should make sure they set
> (or keep the default of) kernel.unprivileged_bpf_disabled at 1 or 2,
> which per the discussion fully removes the exposure of these issues.
>
> Van1sh also recommends restricting access to kernel pointers and
> symbols (which I assume the currently developed eBPF exploits use), and
> monitoring such access, but as I understand this is a general best
> practice and defense-in-depth (on top of not exposing access to eBPF in
> the first place).
>
> Documentation/admin-guide/sysctl/kernel.rst:
>
>> unprivileged_bpf_disabled
>> =========================
>>
>> Writing 1 to this entry will disable unprivileged calls to ``bpf()``;
>> once disabled, calling ``bpf()`` without ``CAP_SYS_ADMIN`` or ``CAP_BPF``
>> will return ``-EPERM``. Once set to 1, this can't be cleared from the
>> running kernel anymore.
>>
>> Writing 2 to this entry will also disable unprivileged calls to ``bpf()``,
>> however, an admin can still change this setting later on, if needed, by
>> writing 0 or 1 to this entry.
>>
>> If ``BPF_UNPRIV_DEFAULT_OFF`` is enabled in the kernel config, then this
>> entry will default to 2 instead of 0.
>>
>> = =============================================================
>> 0 Unprivileged calls to ``bpf()`` are enabled
>> 1 Unprivileged calls to ``bpf()`` are disabled without recovery
>> 2 Unprivileged calls to ``bpf()`` are disabled
>> = =============================================================
>
> kernel/bpf/Kconfig:
>
>> config BPF_UNPRIV_DEFAULT_OFF
>> bool "Disable unprivileged BPF by default"
>> default y
>> depends on BPF_SYSCALL
>> help
>> Disables unprivileged BPF by default by setting the corresponding
>> /proc/sys/kernel/unprivileged_bpf_disabled knob to 2. An admin can
>> still reenable it by setting it to 0 later on, or permanently
>> disable it by setting it to 1 (from which no other transition to
>> 0 is possible anymore).
>>
>> Unprivileged BPF could be used to exploit certain potential
>> speculative execution side-channel vulnerabilities on unmitigated
>> affected hardware.
>>
>> If you are unsure how to answer this question, answer Y.
>
> So these issues shouldn't currently be exposed by default. I tried
> asking if any distros present on the linux-distros list still have
> unprivileged eBPF exposed by default, and no one spoke up.
>
> As to getting the issues fixed, the only information communicated to
> linux-distros was from Willy Tarreau that he transferred Van1sh's
> message to the eBPF maintainers - which is appreciated! It is not
> surprising that such a wide variety of issues not exposed by default
> will take quite a while to process during the summer vacations season.
> Luckily, they're also not that important to review and fix individually.
>
> Given all of this, I reluctantly decided not to make an exception here
> (skipping today's disclosure or limiting it to even less info than was
> on linux-distros), as doing so didn't seem to serve a useful purpose yet
> it would keep further handling by linux-distros in limbo. Now we're
> done handling this on linux-distros, and any further developments should
> be added to this oss-security thread instead.
Are these exploitable via *classic* BPF? The reason I ask is that this
is nearly always available to unprivileged users in the form of seccomp,
and no hardening guide will recommend disabling seccomp-BPF as that is
one of the best tools userspace has to sandbox itself!
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
