Database/Kernel, userspace & hypervisor
Linux kernel BPF verifier: JMP32 comparisons against zero mispredicted, allowing unsafe pointer arithmetic
Impact
The verifier's is_branch_taken() did not distinguish 32-bit from 64-bit comparisons, so a 'if w1 != 0' test against a pointer whose low 32 bits are zero at runtime was reported as always taken. A program can use that to make the verifier accept a path where a pointer is offset by an attacker-chosen value and then dereferenced - a verifier soundness bug, which is the class that leads to arbitrary kernel read and write. On a GPU node this matters wherever unprivileged BPF is reachable or where a workload holds CAP_BPF: it is a local privilege escalation path off a shared node. Most fleets have unprivileged_bpf_disabled set, which removes the unprivileged path.
Who can reach it
Local user able to load BPF programs - either with unprivileged BPF enabled, or a container granted CAP_BPF/CAP_SYS_ADMIN. Not reachable from the network and not reachable at all where unprivileged BPF is off and no workload holds CAP_BPF.
What to do
Apply the stable kernel fix and reboot each node; drain first, since this needs a kernel update rather than a live patch on most distributions. As an immediate mitigation that costs nothing on a typical GPU fleet, confirm kernel.unprivileged_bpf_disabled=1 and audit which pods are granted CAP_BPF or CAP_SYS_ADMIN.
References
Related entries
- Linux kernel BPF: per-CPU map updates accept invalid CPU IDs on sparse CPU masks, corrupting kernel memoryCVE-2026-98150 · Linux kernel BPF (BPF_F_CPU target-CPU validation in bpf_map_check_op_flags)High
- 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
- Linux kernel keyctl: use-after-free reading a key type name during module unloadCVE-2026-99224 · Linux kernel keyctl (KEYCTL_DESCRIBE key type name use-after-free)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
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.