CVE-2026-68399

This CVE exposes a fundamental mismatch between BPF storage's reference-counted ownership model and the kernel's longstanding shallow-copy bail-out patterns in socket operations. The vulnerability: sock_copy() performs an early shallow copy of sk_bpf_storage before bpf_sk_storage_clone() runs, which means newsk->sk_bpf_storage points to parent data that neither socket properly owns. When the child socket is freed, it incorrectly frees storage belonging to the parent, causing state corruption that propagates silently to every subsequent operation on the parent socket — including non-BPF paths that depend on socket metadata. The fix (resetting newsk->sk_bpf_storage to NULL after sock_copy) is elegant but revealing: it makes bpf_sk_storage_clone() functionally irrelevant in this path. This raises a uncomfortable question — if the protection layer existed but wasn't enforcing anything, was the ownership model ever actually correct? The identical pattern was already fixed for fork operations in commit 9b51a6155d14. Two fixes for the same structural flaw in rapid succession signals this is a class of bug, not an isolated mistake. Audit priorities: any sk_clone()-like operation that performs shallow copies before proper initialization is a candidate for this flaw. Beyond sk_clone() and fork(), examine copy operations in inet_csk_clone(), accept()-related paths, and any future refactoring of socket creation code that touches BPF storage. The deeper concern is that BPF local storage was grafted onto infrastructure that predates it and assumes single-threaded, non-shared ownership — a design tension that cannot be contractually patched away. On the now-redundant bpf_sk_storage_clone(): do not remove it. While it becomes a no-op in the sk_clone() path, it remains necessary in fork() and documents the ownership contract. Removing it eliminates a logical checkpoint that future developers rely on to understand intent. The real fix is enforcing the contract at the type level, not surgically removing the safety net. The low EPSS score reflects current exploitability difficulty, but this class of bug — parent object corruption from child cleanup — has historically become exploitable once reliable triggers emerge. The genealogical pattern is consistent: discover, patch narrowly, forget, rediscover. Document this failure class explicitly in commit messages so future reviewers have search terms.

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