CVE-2026-98149: bpf: Fix percpu map update indexing with sparse CPU IDs
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 BPFFCPU or BPFFALLCPUS use a value buffer whose per-CPU slots are packed in possible-CPU order. The buffer is sized as:
roundup(valuesize, 8) numpossiblecpus()
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. BPFFALLCPUS continues to use the same value for every CPU.
Affected Software
Event History
Frequently Asked Questions
Which systems are affected by this issue?
Systems with sparse possible CPU IDs are affected when updating per-CPU array, hash, or cgroup storage maps without BPF_F_CPU or BPF_F_ALL_CPUS. Systems whose possible CPU IDs are contiguous starting at zero do not encounter the incorrect slot indexing described.
What conditions are needed to trigger the problem?
An update must use a packed per-CPU value buffer and iterate across a possible-CPU mask with gaps, such as CPUs 0, 2, and 3. The affected update paths calculate buffer offsets from logical CPU IDs rather than the packed possible-CPU position.
What is the observable impact?
Per-CPU map values can be assigned from incorrect buffer slots. The final sparse CPU can also cause an out-of-bounds read from the supplied update buffer.
Are updates using BPF_F_ALL_CPUS affected?
No. BPF_F_ALL_CPUS continues to use the same value for every CPU and is not described as using the faulty packed-buffer indexing.