Linux kernel BPF: per-CPU map updates accept invalid CPU IDs on sparse CPU masks, corrupting kernel memory

Impact

A local user able to call bpf() can target a per-CPU map operation at a CPU ID that exists in the 0..num_possible_cpus() range but is absent from the possible-CPU mask. The per-CPU access path then memcpy()s to an unmapped per-CPU area, which the report shows as a kernel paging fault in bpf_percpu_array_update - a node-level crash, and potentially memory corruption rather than a clean oops. The same check also wrongly rejects valid high CPU IDs on such systems, so BPF-based tooling silently misreads per-CPU state. Exposure is narrow: it needs a host whose possible-CPU mask has holes (the reporter's case was an arm64 guest with a CPU device-tree gap), which is uncommon on bare-metal GPU nodes but can occur on arm64 VMs and partially populated systems. On a GPU node the practical cost is an unplanned reboot of a box that was mid-training, not a tenancy escape - there is no privilege-boundary crossing described.

Who can reach it

Local user on the host or in a container that is permitted the bpf() syscall (CAP_BPF/CAP_SYS_ADMIN in its namespace, or unprivileged BPF where enabled). Requires a kernel whose cpu_possible mask is sparse. Not reachable from the network and not reachable by a tenant pod that cannot load or operate BPF maps.

What to do

Pick up the fixed stable kernel (commits bdc5941f6eee and ed54bf564ac5, which validate the CPU ID against nr_cpu_ids and cpu_possible()) and reboot each node; there is no runtime mitigation for the check itself. Until then, the exposure can be closed operationally by denying bpf() to tenant workloads - drop CAP_BPF/CAP_SYS_ADMIN from pods and keep unprivileged BPF disabled - which leaves only trusted node agents on the path. The advisory names no fixed release numbers beyond the stable commits.

References

Related entries

• Linux kernel nvme-rdma: double cleanup and DMA unmap after request completion on the -EIO pathCVE-2026-98154 · Linux kernel nvme-rdma (queue_rq -EIO cleanup path)High
• Xen through 4.12.x - passed-through PCI devices left able to DMA into host memory after being handed to an untrustedCVE-2019-18424 · Xen through 4.12.x - passed-through PCI devices left able to DMA into host memory after being handed to an untrusted…Medium
• Xen on AMD-Vi (AMD IOMMU) - ACPI IVMD unity-map page permissions: Xen honours ACPI-described IOMMU unity mappings butCVE-2021-28694 · Xen on AMD-Vi (AMD IOMMU) - ACPI IVMD unity-map page permissionsMedium
• Xen on AMD-Vi - IOMMU page mapping permissions: Second of the XSA-378 IOMMU page-mapping issues on AMD-Vi. IncorrectCVE-2021-28695 · Xen on AMD-Vi - IOMMU page mapping permissionsMedium
• Xen on AMD-Vi - IOMMU page mapping permissions: Third of the XSA-378 AMD-Vi mapping issues. Same practical consequenceCVE-2021-28696 · Xen on AMD-Vi - IOMMU page mapping permissionsMedium
• Linux kernel (arch/x86/kvm): A failed RSM leaves the vCPU's SMM flag and the MMU role out of sync, so KVM resolves aCVE-2021-47230 · Linux kernel (arch/x86/kvm)Medium