CVE-2026-89579: bpf: Harden bloom filter sizing and indexing on 32-bit kernels

In the Linux kernel, the following vulnerability has been resolved:

bpf: Harden bloom filter sizing and indexing on 32-bit kernels

bloommapalloc() has two 32-bit-specific problems when the computed bitmap reaches the U32MAX fallback case.

First, BITSTOBYTES(U32MAX) is evaluated with 32-bit arithmetic. The addition performed by DIVROUNDUP wraps, so the map allocates only the fixed-size bloom filter object while keeping bitsetmask == U32MAX. 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 setbit() takes a signed long bit number and x86 testbit() eventually feeds the index to variabletestbit(long, ...). On 32-bit kernels, hashes in [0x80000000, U32MAX] therefore become negative bit offsets. x86 bt/bts with a memory operand interpret those offsets relative to the supplied base, so a map with bitsetmask == U32MAX can read or write before bloom->bitset even after allocating the full 512 MiB bitmap.

Keep the U32MAX fallback, but split each hash into a word pointer and an in-word bit number before calling testbit() or setbit(). The bitops argument is then always in [0, BITSPERLONG - 1], while BITWORD(h) still selects the intended word in the full bitmap.

Compute the bitset size from (u64)bitsetmask + 1 before passing the final size to bpfmapareaalloc(). 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 CAPBPF.