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.