---
id: CVE-2026-89579
title: 'bpf: Harden bloom filter sizing and indexing on 32-bit kernels'
summary: |-
  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…
severity: high
cvss: 7.8
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
cvssSource: cna
cwe:
  - CWE-787
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 9330986c03006ab1d33d243b7cfe598a7a3c1baa <
    a6183bc683f97f4317f7e84939ca7fff37c5688b
  - >-
    Linux >= 9330986c03006ab1d33d243b7cfe598a7a3c1baa <
    80551bf8912c42d1e3d55eec6fa3c40f306c3de8
  - >-
    Linux >= 9330986c03006ab1d33d243b7cfe598a7a3c1baa <
    3b7a13eccfcf97714ffc1ca6aa663d66d4a30e29
  - >-
    Linux >= 9330986c03006ab1d33d243b7cfe598a7a3c1baa <
    272fcb4ba6fab678db0eb966dc81c4c804bef64a
  - >-
    Linux >= 9330986c03006ab1d33d243b7cfe598a7a3c1baa <
    dff481e12b3f127739f6a4ea7cef2c25dc12e056
  - >-
    Linux >= 9330986c03006ab1d33d243b7cfe598a7a3c1baa <
    11c1e836710dcba03e50454a4eedfdbaf8d3050e
  - Linux 5.16
published: '2026-09-11'
updated: '2026-10-19'
sourceUpdated: '2026-10-19T08:49:12.203Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-89579'
references:
  - url: 'https://git.kernel.org/stable/c/a6183bc683f97f4317f7e84939ca7fff37c5688b'
  - url: 'https://git.kernel.org/stable/c/80551bf8912c42d1e3d55eec6fa3c40f306c3de8'
  - url: 'https://git.kernel.org/stable/c/3b7a13eccfcf97714ffc1ca6aa663d66d4a30e29'
  - url: 'https://git.kernel.org/stable/c/272fcb4ba6fab678db0eb966dc81c4c804bef64a'
  - url: 'https://git.kernel.org/stable/c/dff481e12b3f127739f6a4ea7cef2c25dc12e056'
  - url: 'https://git.kernel.org/stable/c/11c1e836710dcba03e50454a4eedfdbaf8d3050e'
  - url: >-
      https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89579.json
  - url: 'https://access.redhat.com/security/cve/CVE-2026-89579'
  - url: 'https://bugzilla.redhat.com/show_bug.cgi?id=2532482'
  - url: 'https://www.cve.org/CVERecord?id=CVE-2026-89579'
  - url: 'https://nvd.nist.gov/vuln/detail/CVE-2026-89579'
  - url: >-
      https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-89579.mbox
tags:
  - cve.org
  - csaf
  - vex
  - red-hat
epss: 0.00167
epssPercentile: 0.05932
scores:
  cna: 7.8
  vendor: 6.7
ingestedAt: '2026-09-14T15:23:07.451Z'
---

## Overview

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.

## Affected

- `Linux >= 9330986c03006ab1d33d243b7cfe598a7a3c1baa < a6183bc683f97f4317f7e84939ca7fff37c5688b`
- `Linux >= 9330986c03006ab1d33d243b7cfe598a7a3c1baa < 80551bf8912c42d1e3d55eec6fa3c40f306c3de8`
- `Linux >= 9330986c03006ab1d33d243b7cfe598a7a3c1baa < 3b7a13eccfcf97714ffc1ca6aa663d66d4a30e29`
- `Linux >= 9330986c03006ab1d33d243b7cfe598a7a3c1baa < 272fcb4ba6fab678db0eb966dc81c4c804bef64a`
- `Linux >= 9330986c03006ab1d33d243b7cfe598a7a3c1baa < dff481e12b3f127739f6a4ea7cef2c25dc12e056`
- `Linux >= 9330986c03006ab1d33d243b7cfe598a7a3c1baa < 11c1e836710dcba03e50454a4eedfdbaf8d3050e`
- `Linux 5.16`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

## Vendor advisories

- **Red Hat VEX** · Moderate · affected: Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9 · no fix planned: Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9 · updated 2026-09-27 · [vex](https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89579.json)