This CVE reveals more than a single ordering bug in RDS TCP — it exposes a structural anti-pattern where sysctl handlers implicitly depend on kernel objects whose teardown order was never formally modeled. The handler rds_tcp_skbuf_handler() derives its network namespace context from rds_tcp_listen_sock->sk, creating a contractual relationship between the handler and socket lifetime that the sysctl subsystem has no mechanism to flag or enforce. KASAN caught the race cleanly, but KASAN requires compile-time instrumentation absent from production kernels by default — if this race window is narrow, it may persist undetected in production systems.
The historical record suggests this isn't isolated. The same pattern — sysctl handler derives context from a network object that races with netns teardown — has surfaced in IPv6 addrconf, netfilter per-ns tables, and wireless netns cleanup. Each fix was structurally identical: unregister before teardown. When the same remediation repeats across decades and subsystem boundaries, you're looking at a class vulnerability, not a one-off oversight. The sysctl API was designed for a kernel where subsystems cleaned up in implied reverse-initialization order; network namespaces introduced asynchronous, concurrent teardown that broke that model.
What you should do: audit network subsystems where handlers access objects registered to netns but whose teardown was added post-netns-concurrency. Focus on handlers that reach into objects with downstream consumers across the namespace — those have blast radius beyond the immediate UAF. The question isn't just whether RDS TCP got this wrong, but whether other netns teardown paths manage sysctl unregistration and object destruction as separate concerns rather than a coordinated lifecycle. The fix for this specific instance is correct, but the class-level fix — systematic prevention — remains outstanding after more than a decade of these same patterns recurring.