Cloudanix VulnDB

CVE-2026-98150

High · 7.0

CVSS

7.0

EPSS

0.1%

Published

Sep 25, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel can let a program on the same computer feed bad information to a performance feature and crash the whole machine or gain extra access.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
High
Impact
Full Compromise
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The BPF map operation flag validation in bpf_map_check_op_flags() incorrectly uses num_possible_cpus() instead of nr_cpu_ids() and cpu_possible(), allowing invalid or sparse CPU IDs to reach per-CPU map access paths and trigger out-of-bounds memory operations.

Why it matters to the business

Local users can trigger kernel crashes or memory corruption on systems with non-contiguous CPU IDs, leading to denial of service and potential privilege escalation on Linux hosts.

How an attack unfolds

An attacker with local access issues raw bpf() syscalls against a PERCPU_ARRAY map, supplying BPF_F_CPU plus an out-of-range CPU ID in the flags; the missing validation lets the request reach bpf_percpu_array_update() which performs an invalid memcpy and panics the kernel.

How to fix it

Upgrade the Linux kernel to a version containing the fix for CVE-2026-98150; rebuild and reboot with the corrected bpf_map_check_op_flags() logic that checks nr_cpu_ids() and cpu_possible().

How to confirm the fix worked

Confirm kernel source contains the updated comparison against nr_cpu_ids() and cpu_possible(); test that BPF operations with CPU IDs outside the possible mask now correctly return -ERANGE.

Typical attack path

  1. Obtain local unprivileged shell on affected Linux system
  2. Create BPF_MAP_TYPE_PERCPU_ARRAY map via raw syscall
  3. Issue map update/lookup with BPF_F_CPU flag and invalid CPU ID
  4. Trigger kernel paging fault in percpu access path

How to detect it

Search kernel logs for Unable to handle kernel paging request combined with bpf_percpu_array_update or __pi_memcpy_generic call traces; review audit logs for raw bpf() syscalls using BPF_F_CPU.

  • bpf_percpu_array_update
  • __pi_memcpy_generic
  • map_update_elem
  • Unable to handle kernel paging request at virtual address

What your security team should do

  • Prioritize kernel upgrade on all systems with sparse CPU topologies within 30 days
  • Audit local unprivileged users who can issue bpf() syscalls
  • Monitor for kernel oops involving bpf_percpu_array_update

The record

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.

Affected packages

Ecosystem Package Introduced Fixed