GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel BPF: per-CPU map updates index by logical CPU id, reading past the update buffer

CVSS 7.8CVE-2026-98149Kernel, userspace & hypervisorcurated

Impact

Per-CPU array, hash and cgroup-storage map updates without BPF_F_CPU or BPF_F_ALL_CPUS use a value buffer sized round_up(value_size, 8) * num_possible_cpus(), with slots packed in possible-CPU order. The update paths iterated possible CPUs but computed the source offset from the logical CPU id, which is only correct when possible CPU ids are contiguous from zero. With a sparse possible-CPU mask - 0,2-3 in the kernel's own example - the last CPU reads past the end of the update buffer and every offline-gap CPU gets the wrong value. Sparse CPU masks are not exotic on large NUMA GPU hosts and on nodes where CPUs are offlined for isolation, so this is both a kernel out-of-bounds read and a silent data-correctness bug in per-CPU maps that observability and networking agents rely on.

Who can reach it

Local caller of bpf() map update on a per-CPU map - any process or container with BPF map access - on a host whose possible-CPU ids are non-contiguous. No remote path.

What to do

Update to a stable kernel with the fix that advances the source offset once per possible CPU in the array, hash and cgroup-storage update paths, matching the lookup paths; both commits are in the record. Kernel package plus node reboot. As an interim check, confirm whether your hosts actually have a sparse possible-CPU mask - on nodes with contiguous ids the bug does not trigger.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.