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)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
