CVE-2026-72426

This CVE is not an isolated bug — it is the fourth known manifestation of a vulnerability family rooted in how BPF's verifier communicates security-critical type information to runtime cleanup passes. The pattern traces back through CVE-2022-1048, CVE-2021-4202, and CVE-2020-27194, each patched conservatively, none resolved structurally. The underlying issue: the BPF verifier tracks pointer/spill metadata as abstract state during verification, but runtime cleanup passes like __clean_func_state() operate on raw stack bytes. When cleanup clears dead stack halves, it cannot distinguish between a pointer spill and a scalar spill — because that knowledge lives in the verifier's interpretation, not in the runtime's data structure. The current fix addresses this by preserving pointer spill slots intact while still allowing cleanup of scalar slots. This corrects the immediate security failure but introduces a new asymmetry: the code now makes security decisions based on metadata it itself may have corrupted in earlier passes. More concerning, the fix encodes an explicit rule ('leave pointer spill slots alone') that didn't exist in the original design, creating new load-bearing assumptions attackers can probe in future optimization passes. The deeper problem is architectural: BPF lacks an enforced contract separating what the verifier knows from what cleanup assumes. Until that separation is made structurally impossible to violate — not policed through special cases — this vulnerability family will continue producing offspring. Treat each CVE in this lineage as evidence that the verifier-to-runtime handoff carries unresolved security debt. Monitor not just whether your kernels are patched, but whether any custom BPF programs, legacy JIT paths, or deprecated syscalls might exercise code paths that predated this fix and remain unpatched.

Reviewed through automated stages and approved by a human before publication.