bpf: Harden bloom filter sizing and indexing on 32-bit kernels
Summary
| CVE | CVE-2026-89579 |
|---|
| State | PUBLISHED |
|---|
| Assigner | Linux |
|---|
| Source Priority | CVE Program / NVD first with legacy fallback |
|---|
| Published | 2026-09-11 20:19:42 UTC |
|---|
| Updated | 2026-09-11 20:19:42 UTC |
|---|
| Description | 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. |
|---|
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|
| CNA |
Linux |
Linux |
affected 9330986c03006ab1d33d243b7cfe598a7a3c1baa 3b7a13eccfcf97714ffc1ca6aa663d66d4a30e29 git |
Not specified |
| CNA |
Linux |
Linux |
affected 9330986c03006ab1d33d243b7cfe598a7a3c1baa 272fcb4ba6fab678db0eb966dc81c4c804bef64a git |
Not specified |
| CNA |
Linux |
Linux |
affected 9330986c03006ab1d33d243b7cfe598a7a3c1baa dff481e12b3f127739f6a4ea7cef2c25dc12e056 git |
Not specified |
| CNA |
Linux |
Linux |
affected 9330986c03006ab1d33d243b7cfe598a7a3c1baa 11c1e836710dcba03e50454a4eedfdbaf8d3050e git |
Not specified |
| CNA |
Linux |
Linux |
affected 5.16 |
Not specified |
| CNA |
Linux |
Linux |
unaffected 5.16 semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.12.109 6.12.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.18.50 6.18.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.2.4 7.2.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.3-rc1 * original_commit_for_fix |
Not specified |
References
| Reference | Source | Link | Tags |
|---|
| git.kernel.org/stable/c/3b7a13eccfcf97714ffc1ca6aa663d66d4a30e29 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/dff481e12b3f127739f6a4ea7cef2c25dc12e056 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/272fcb4ba6fab678db0eb966dc81c4c804bef64a |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/11c1e836710dcba03e50454a4eedfdbaf8d3050e |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| CVE Program record |
CVE.ORG |
www.cve.org |
canonical |
| NVD vulnerability detail |
NVD |
nvd.nist.gov |
canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.