KernelScan.io

HIGH Introduced in 7.0

bpf CpuId Deref

CVE-2026-98150

CVSS 7.0 / 10.0 NVD

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

KernelScan AI7.8HIGH

01

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix BPF_F_CPU validation for sparse CPU IDs BPF_F_CPU stores the target CPU ID in the upper 32 bits of the map operation flags. bpf_map_check_op_flags() currently compares that ID with num_possible_cpus(), 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 BPF_MAP_TYPE_PERCPU_ARRAY and performs update and lookup operations for each CPU by setting BPF_F_CPU 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 : __pi_memcpy_generic+0x5c/0x22c lr : bpf_percpu_array_update+0x2dc/0x2e8 Call trace: __pi_memcpy_generic bpf_map_update_value map_update_elem __sys_bpf Check the CPU ID against nr_cpu_ids and cpu_possible() instead. This rejects CPU IDs outside the valid range and CPUs absent from the possible mask, while allowing valid sparse CPU IDs.

02

Engine v0.6.0

Risk summary

A local attacker with BPF map access can crash the kernel by specifying a CPU ID that passes a flawed bounds check on systems with sparse CPU topologies. The bug causes the kernel to access per-CPU data for a non-existent CPU, triggering an unrecoverable paging fault. Systems running untrusted BPF workloads or multi-tenant containers are most at risk.

Affectedinclude/linux/bpf.h (bpf)

Vulnerability analysis

When a userspace program asks the kernel to access a per-CPU BPF map while targeting a specific CPU, the kernel checks the requested CPU number against the total count of possible CPUs rather than the highest valid CPU identifier. On systems where CPU numbering has gaps—such as when only processors 0, 2, and 3 exist—a non-existent CPU can pass validation and reach the internal per-CPU data path. That access then touches unmapped kernel memory and crashes the system. The corrected check now ensures the CPU number is within the valid identifier range and that the processor actually exists in the system, blocking requests that target missing CPUs. A local process can reach this through the BPF system call; triggering it requires BPF privileges, which an unprivileged process may acquire through a user namespace on some configurations.

03

BranchIntroducedFixed inPatch commit
7.27.07.2.7bdc5941f6eee
mainline7.07.3ed54bf564ac5