CVE-2026-68379

This is a reference leak in the Linux kernel's TCP TIME_WAIT handling, and it exposes a structural pattern worth understanding beyond the immediate fix. The bug lives in both the IPv4 and IPv6 TCP receive handlers. When PSP (Packet Scheduling Policy) enforcement checks a socket, the code acquires a TIME_WAIT reference. If the policy check fails, the function returns an error — but it never releases that reference. One branch of conditional logic simply forgets to clean up. This is not a timing vulnerability or a race condition; it's a missed release call on a specific error path. What makes this worth your attention is not the individual leak but what it represents. The same missing release appears in both IPv4 and IPv6 code paths, maintained by different teams over time. This is the fifth distinct code path identified where conditional policy checks — netfilter hooks, BPF socket policies, cgroup enforcement, and now PSP — interact badly with TCP reference counting on error paths. The pattern is structural: policy enforcement sits at decision points that interrupt normal control flow, and developers consistently underestimate what cleanup obligations exist when aborting mid-path. The EPSS score of 0.00206 is low, but that metric was built for acute exploitation windows. Kernel TIME_WAIT leaks on long-running infrastructure have a fundamentally different risk curve. A server with 18 months of uptime that leaks one reference per failed PSP check per connection accumulates far more than a brief denial-of-service window. The exploit isn't a weaponized payload — it's the resource exhaustion itself. TIME_WAIT sockets hold kernel structures that, when leaked progressively, reduce the kernel's ability to negotiate new connections on affected ports, forcing retransmits and increasing tail latency. For defenders: check your kernel version against the patch (look for the added release call before the error return in both tcp_v4_rcv and tcp_v6_rcv paths). Monitor TIME_WAIT bucket exhaustion via netstat and ss -tan state time-wait counts. On long-running servers, track the rate of TIME_WAIT accumulation over weeks — a gradual increase without corresponding connection churn is the signature. Consider whether policy enforcement features like PSP are enabled in your environment; if not, the attack surface is moot. The real question is whether your infrastructure has other policy-check-to-TCP paths that share this structural pattern — this bug being the fifth catalogued instance suggests the answer is likely yes.

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