Linux kernel BPF verifier: dead zero spill downgraded to STACK_ZERO breaks precision tracking

CVSS 5.5CVE-2026-98132Kernel, userspace & hypervisorcurated

Impact

The verifier's state-pruning pass could rewrite a 64-bit scalar zero spill into a partially poisoned STACK_ZERO slot without marking the zero source precise, breaking precision propagation chains. Broken precision tracking means the verifier can accept a program whose stack state it has mis-modelled, and the record scores the outcome as availability loss only (host crash / hang), with no confidentiality or integrity impact claimed. On a GPU node this matters because the blast radius is the whole host: a panic takes every co-tenant GPU pod on the box with it and the node has to be drained and rebooted rather than hot-patched. Reachability depends on who can load BPF programs - on a fleet where unprivileged BPF is disabled and only the node agent, CNI and observability stack load programs, no tenant can reach this path at all.

Who can reach it

Local, authenticated: a user or container able to load a BPF program (CAP_BPF/CAP_SYS_ADMIN, or an unprivileged-BPF-enabled host). Not reachable over the network and not reachable by a pod that cannot call bpf().

What to do

Take the stable-tree fix (commits 2f3536bff882 and 436fa689630b) via your distribution kernel, then drain and reboot each node; there is no runtime mitigation for a verifier bug short of blocking BPF program loading. Interim hardening: keep kernel.unprivileged_bpf_disabled=1 and withhold CAP_BPF from tenant workloads, which removes tenant reachability. The record names no fixed release version.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-98132 https://git.kernel.org/stable/c/2f3536bff8823d3c5fdbbe15e17bfca696cc2b2e https://git.kernel.org/stable/c/436fa689630b741a77ef8c4a6f426479affd5bac

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.