CVE-2026-72423

CVE-2026-72423 exposes a fundamental mismatch in BPF's safety architecture. The BPF verifier validates that the `opts__sz` parameter describes a safe memory region, but the conntrack kfunc implementation unconditionally writes to `opts->error` at a fixed struct offset. These two operations — the verifier's size check and the kfunc's write — operate on different mental models of the same data structure. Code passes verification while performing an unsafe write; the safety contract is mechanically decoupled rather than enforced as a unified constraint. This is not a developer error. The API design separates size validation from write operations by design, giving developers no signal when they're authoring a divergence. The pattern — where a size parameter validates one region while the implementation writes to a fixed offset in another — has deep roots in C systems programming. It appeared in ioctl handlers (CVE-2009-2689), in netlink protocol handlers (CVE-2016-9794), and now in BPF kfuncs. The lineage is clear: classic heap buffer overflows evolved into this more insidious variant where verification covers your safety check but not your actual operation. What elevates this CVE is the blast radius. BPF executes in kernel context with access to conntrack state. The write doesn't corrupt a userspace buffer — it corrupts kernel connection tracking tables through a pathway the verifier explicitly blessed. The CVSS of 8.8 undersells the real impact because scoring frameworks don't capture the systemic risk of verified BPF code reaching into kernel subsystems through a pattern the verifier didn't fully model. The conntrack tables written through this path may have been contaminated in production long before anyone passed an undersized opts. The fix — guarding the write — is trivial. But it won't prevent the next similar gap. BPF has hundreds of kfuncs, many using opts patterns, and the ones that haven't produced a CVE are likely working by accident rather than by mechanical guarantee. The honest assessment is that you'll likely see 8-15 similar patches across the kfunc surface in the next two kernel release cycles as auditors apply systematic scrutiny. What you should do: audit every kfunc in your BPF programs that takes an opts structure and a size parameter. The critical question isn't whether the size validates the region — it's whether the implementation's actual writes are a subset of that validated region. Prioritize kfuncs that touch interconnected kernel state (network buffers, namespace data, scheduling structures) where a divergence cascades into systemic contamination rather than local corruption. The blast radius of the next gap will be worst in those subsystems.

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