Cloudanix VulnDB

CVE-2026-98149

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Sep 25, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in how the Linux kernel handles certain performance-related data structures on systems with unusual CPU numbering can let a local user read or damage internal memory, potentially taking over the machine.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Incorrect indexing into per-CPU value buffers during BPF map updates for array, hash, and cgroup storage maps causes out-of-bounds reads when the system has sparse CPU IDs; the code uses logical CPU numbers instead of dense possible-CPU offsets, leading to reads from uninitialized or invalid buffer locations and potential memory corruption.

Why it matters to the business

Local attackers can trigger kernel memory corruption that may result in privilege escalation, system crashes, or arbitrary code execution; the issue affects all Linux distributions using recent kernels with BPF support, increasing operational risk on multi-core systems with non-contiguous CPU numbering.

How an attack unfolds

An attacker with local access loads a BPF program that performs per-CPU map updates without BPF_F_CPU or BPF_F_ALL_CPUS flags on a system with sparse CPU IDs; the update path calculates source offsets using logical CPU IDs, reading past the allocated buffer and allowing the attacker to influence kernel memory or cause controlled crashes that can be leveraged for further exploitation.

How to fix it

Apply the upstream kernel patch that changes the update paths to iterate using dense possible-CPU offsets instead of logical CPU IDs; rebuild and deploy fixed kernel packages for all affected distributions; test on systems with known sparse CPU masks before broad rollout.

How to confirm the fix worked

Boot a test kernel on hardware or in a VM configured with a sparse CPU mask (e.g., CPU 0,2-3), exercise BPF per-CPU map updates, and verify no out-of-bounds accesses occur via kernel memory debugging tools or by confirming the fix commit is present in the running kernel source.

Typical attack path

  1. Obtain local unprivileged access to a Linux system
  2. Identify or force a sparse possible-CPU mask
  3. Load a BPF program performing per-CPU array/hash/cgroup storage updates
  4. Trigger map update operations that use logical CPU indexing
  5. Read or corrupt adjacent kernel memory via the resulting out-of-bounds access

How to detect it

Review kernel logs for unexpected page faults or slab corruption during BPF map update syscalls; inspect audit logs for unusual bpf() calls from non-root users; correlate with systems that have non-contiguous CPU IDs visible in /proc/cpuinfo or dmesg.

What your security team should do

  • Prioritize kernel updates on all multi-core production systems within the next maintenance window
  • Audit any custom BPF programs that rely on per-CPU maps for update patterns
  • Enable kernel memory safety mitigations such as KASAN in test environments to catch regressions
  • Monitor for downstream distribution advisories that backport the fix

The record

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix percpu map update indexing with sparse CPU IDs Per-CPU array, hash, and cgroup storage map updates without BPF_F_CPU or BPF_F_ALL_CPUS use a value buffer whose per-CPU slots are packed in possible-CPU order. The buffer is sized as: round_up(value_size, 8) * num_possible_cpus() The update paths iterate over possible CPUs, but use the logical CPU ID to calculate the source offset: value + size * cpu This only works when possible CPU IDs are contiguous starting at zero. For example, with a possible CPU mask of 0,2-3, the buffer contains three slots corresponding to CPUs 0, 2, and 3. CPU2 is therefore expected to use slot 1 and CPU3 slot 2. Instead, the current code uses slots 2 and 3 respectively, causing incorrect per-CPU values and an out-of-bounds read from the update buffer for CPU3. The corresponding lookup paths already use a dense offset while iterating over possible CPUs. Do the same for the array, hash, and cgroup storage update paths, advancing the source offset once for each possible CPU. BPF_F_ALL_CPUS continues to use the same value for every CPU.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities