CVE-2026-89579

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.