Re: Linux kernel: eBPF vulnerabilities

[Demi Marie Obenour <demiobenour () gmail com>]

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)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature