CVE-2026-89579
nicheOut-of-bounds BPF bloom filter writes enable local privilege escalation in 32-bit Linux
The Linux kernel's BPF bloom filter map contains two related 32-bit arithmetic flaws that allow out-of-bounds memory reads and writes. When a map is sized so that bitset_mask equals U32_MAX, BITS_TO_BYTES() overflows 32-bit arithmetic and the map is under-allocated while updates continue to index the full 512 MiB bitset, letting writes run past the allocated object; separately, bloom hashes at or above 0x80000000 are treated as negative signed long bit offsets by test_bit()/set_bit() on 32-bit x86, causing accesses before the bitset even when correctly allocated. A local attacker on a 32-bit x86 kernel who can load BPF maps (i.e., holds CAP_BPF, or runs where unprivileged BPF is enabled) can trigger these flaws for kernel memory corruption and full local privilege escalation. Affected systems are those running 32-bit x86 Linux kernels without the fix, which mainly means legacy desktops, older virtualized guests, and some embedded or appliance deployments. No public proof of concept is known and the flaw is not listed in the CISA KEV catalog.
What to do: Patch to a kernel containing the bloom filter sizing/indexing fix (via your distribution's stable or backported kernel update) as soon as it is available, prioritizing any 32-bit x86 hosts. As defense in depth, verify that unprivileged BPF is disabled (kernel.unprivileged_bpf_sysctl = 0) and tightly restrict which users/processes hold CAP_BPF or CAP_SYS_ADMIN on multi-user 32-bit systems. Inventory for i386/i686 kernel deployments — these are the only systems needing urgent action for this CVE.
| Linux kernel (BPF bloom filter map, 32-bit kernels) | 32-bit x86 kernel builds lacking the fix; the advisory does not specify exact version ranges, so defenders should track their distro's stable/backport advisorie |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: bpf: Harden bloom filter sizing and indexing on 32-bit kernels bloom_map_alloc() has two 32-bit-specific problems when the computed bitmap reaches the U32_MAX fallback case. First, BITS_TO_BYTES(U32_MAX) is evaluated with 32-bit arithmetic. The addition performed by DIV_ROUND_UP wraps, so the map allocates only the fixed-size bloom filter object while keeping bitset_mask == U32_MAX. Subsequent updates can then write past the allocated object. Second, fixing only the allocation size is not sufficient. The bloom hash is a u32, but set_bit() takes a signed long bit number and x86 test_bit() eventually feeds the index to variable_test_bit(long, ...). On 32-bit kernels, hashes in [0x80000000, U32_MAX] therefore become negative bit offsets. x86 bt/bts with a memory operand interpret those offsets relative to the supplied base, so a map with bitset_mask == U32_MAX can read or write before bloom->bitset even after allocating the full 512 MiB bitmap. Keep the U32_MAX fallback, but split each hash into a word pointer and an in-word bit number before calling test_bit() or set_bit(). The bitops argument is then always in [0, BITS_PER_LONG - 1], while BIT_WORD(h) still selects the intended word in the full bitmap. Compute the bitset size from (u64)bitset_mask + 1 before passing the final size to bpf_map_area_alloc(). This fixes the original under-allocation and keeps the allocated storage consistent with the addressable bitset. Exploitation note: local privilege escalation is possible on a 32-bit x86 kernel using the under-allocation bug from a binary with CAP_BPF.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.