CVE-2026-98150: bpf: Fix BPF_F_CPU validation for sparse CPU IDs
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix BPFFCPU validation for sparse CPU IDs
BPFFCPU stores the target CPU ID in the upper 32 bits of the map operation flags. bpfmapcheckopflags() currently compares that ID with numpossiblecpus(), which is the number of possible CPUs rather than a bound on CPU IDs.
On an arm64 QEMU guest with a CPU device-tree hole, the possible CPU mask was 0,2-3. A userspace program using raw bpf() syscalls creates a BPFMAPTYPEPERCPUARRAY and performs update and lookup operations for each CPU by setting BPFFCPU and the CPU ID in the flags.
With the old check, CPU 1 is incorrectly accepted while valid CPU 3 is rejected with -ERANGE. The CPU 1 update then reaches the per-CPU map access path and triggers:
Unable to handle kernel paging request at virtual address ... pc : pimemcpygeneric+0x5c/0x22c lr : bpfpercpuarrayupdate+0x2dc/0x2e8 Call trace: pimemcpygeneric bpfmapupdatevalue mapupdateelem sysbpf
Check the CPU ID against nrcpuids and cpupossible() instead. This rejects CPU IDs outside the valid range and CPUs absent from the possible mask, while allowing valid sparse CPU IDs.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to the incorrect validation?
Systems with sparse possible CPU IDs, such as the described arm64 QEMU guest whose possible CPU mask is 0,2-3, are affected. The issue occurs when BPF per-CPU map operations use BPF_F_CPU to select a CPU ID.
What does an attacker or triggering program need to do?
A userspace program must issue raw bpf() syscalls against a BPF_MAP_TYPE_PERCPU_ARRAY and set BPF_F_CPU with a CPU ID. An ID that is below the number of possible CPUs but absent from the possible CPU mask can be incorrectly accepted.
What is the impact of using an invalid CPU ID?
An invalid sparse CPU ID can reach the per-CPU map access path during an update and trigger a kernel paging request, as shown in the reported bpf_percpu_array_update call trace. Conversely, valid higher sparse CPU IDs can be rejected with -ERANGE.
How can administrators identify a potentially affected configuration?
Check whether the system's possible CPU mask has holes, meaning valid CPU IDs are not a contiguous range starting at zero. On such systems, test whether BPF_F_CPU operations accept an absent CPU ID or reject a CPU ID that is present in the possible mask.
What behavior changes after the fix?
The corrected validation checks CPU IDs against nr_cpu_ids and cpu_possible(). It rejects IDs outside the valid range or absent from the possible CPU mask while allowing valid sparse CPU IDs.