CVE-2026-74256

The CVSS 8.4 score for this integer overflow in sockmap's scatterlist handling obscures a more fundamental question: why did the BPF verifier—the gatekeeper that stands between untrusted BPF programs and kernel memory—fail to catch this class of arithmetic bypass? The bug itself is straightforward. A pop operation on a socket message queue, stored as a signed int, wraps when it exceeds the scatterlist length field (a u32), producing a negative index that bypasses bounds checking and dereferences a null pointer via put_page(). The fix—casting to u64 before addition—is correct and trivial. What isn't trivial is what this reveals about the verifier's scope. This is the third time in four years the BPF verifier has failed to catch arithmetic wraps in scatterlist-adjacent code paths. CVE-2020-27194 (verifier bounds on percpu map lookup), CVE-2022-2327 (sockmap msg_push_data length confusion), and now this. Each CVE is scored and patched as an isolated event. Each fix is correct. But the pattern—the verifier abstracting over runtime scatterlist state it cannot own—is not a specific gap that was patched. It's a structural limitation that the CVE process keeps labeling 'fixed' because a commit landed. The exploitation primitive matters here more than the CVSS score suggests. The null pointer dereference isn't a crash—it's a controlled kernel dereference of a msg slot that the BPF program staged beforehand. This is a verifier bypass that lets a BPF program manipulate kernel scatterlist state to produce a kernel memory operation it controls. If unprivileged BPF can reach sockmap verdict points, the threat actor shifts from 'kernel developer with a bad merge' to 'containerized workload with BPF program loading rights.' That's a fundamentally different threat model that CVSS's attack complexity and privileges-required vectors don't capture well. The type discipline failure compounds this. The secondary fix—changing pop from int to u32—reveals that the kernel's own type hygiene in this subsystem was inconsistent. Mixed signed/unsigned arithmetic in security-critical scatterlist manipulation is a design smell, not just an implementation bug. The linter gap devfriction identifies is real: no tool fires on 'this signedness combination will bite you when arithmetic wraps at 32 bits.' The verifier doesn't catch it because the verifier's job is proving safety properties, not enforcing API contract hygiene across subsystem boundaries. The question for defenders isn't whether to patch—it is to understand the exposure window. If this verifier scatterlist abstraction failure has appeared three times in four years, you've had three separate exposure windows where BPF-assisted networking deployments operated under false guarantees. The compounding risk isn't just that each fix is isolated; it's that each iteration resets the clock on a class of flaw the ecosystem keeps treating as discrete rather than chronic. Audit your BPF deployments for sockmap usage, verify unprivileged BPF loading is restricted if sockmap verdict points are reachable, and treat this not as a one-off overflow but as evidence that the verifier's claim to be the definitive safety boundary for scatterlist operations has genuine gaps.

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