CVE-2026-98150 in Linux
Summary
by MITRE • 09/25/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel contains a validation flaw within the Berkeley Packet Filter (BPF) subsystem specifically affecting the handling of per-CPU array map operations when utilizing the BPF_F_CPU flag. This flag is designed to store the target Central Processing Unit identifier in the upper thirty-two bits of the map operation flags, allowing userspace programs to direct updates and lookups to specific CPU cores for performance optimization via cache locality. The vulnerability arises from an incorrect boundary check implemented in the bpf_map_check_op_flags function, which validates these identifiers against num_possible_cpus rather than ensuring they fall within the valid range defined by nr_cpu_ids or are present in the cpu_possible mask. This logical error creates a discrepancy between the number of possible CPUs and the maximum allowable CPU identifier index, leading to improper acceptance of invalid IDs and rejection of valid ones under certain hardware configurations.
The operational impact of this flaw is particularly evident on architectures such as arm64 running within QEMU virtual machines where the device tree defines sparse or non-contiguous CPU topologies with gaps in the possible CPU mask. In scenarios where the possible CPU mask excludes specific identifiers, such as a gap at CPU one while CPUs two and three are active, the flawed validation logic incorrectly accepts updates targeting the absent CPU identifier because it is numerically less than num_possible_cpus. Conversely, valid operations targeting existing but higher-numbered sparse CPUs may be rejected with an ERANGE error due to exceeding the count rather than checking actual existence. When an invalid update for a non-existent or out-of-bounds CPU ID like CPU one proceeds through the kernel path, it triggers a critical failure in memory access routines. Specifically, the bpf_percpu_array_update function attempts to perform operations on per-CPU data structures that do not exist for that identifier, resulting in an unable to handle kernel paging request error at virtual addresses accessed by functions such as __pi_memcpy_generic and map_update_elem.
This vulnerability represents a classic case of improper input validation leading to out-of-bounds memory access or invalid pointer dereference within the kernel space. From a classification perspective, this aligns with CWE-125 Out-of-bounds Read if the operation results in reading uninitialized data, or more critically CWE-787 Out-of-bounds Write if the memcpy operations attempt to write into unmapped or incorrect memory regions associated with non-existent per-CPU arrays. The attack vector involves a local user executing raw bpf system calls to manipulate BPF maps, which falls under MITRE ATT&CK technique T1059 Command and Scripting Interpreter via kernel-level APIs, although the primary impact here is denial of service through kernel panic rather than privilege escalation or code execution in this specific manifestation. The lack of strict bounds checking against both the total number of CPU IDs and the actual presence of those CPUs in the system topology allows for these erroneous state transitions that destabilize the operating environment.
To mitigate this vulnerability, it is essential to apply the upstream kernel patch that corrects the validation logic within bpf_map_check_op_flags. The fix requires replacing the comparison against num_possible_cpus with checks against nr_cpu_ids and verifying membership in the cpu_possible mask using appropriate bit manipulation functions like cpumask_test_cpu. This ensures that only CPU identifiers corresponding to physically or logically present processors are accepted for BPF map operations, thereby preventing invalid memory accesses triggered by sparse topology configurations. System administrators should ensure their Linux kernels are updated to versions containing this fix, particularly if running on ARM64 platforms with virtualized environments or custom device trees that define non-contiguous CPU sets. Regular patching and adherence to kernel security updates remain the primary defense against such logic errors in low-level subsystems like BPF which interact directly with hardware topology abstractions.