CVE-2026-68377

The vulnerability in act_tunnel_key stems from a structural assumption that proved false: the developer believed that because the params struct and its embedded dst were allocated together, they could be released together. They cannot. The params struct uses kfree_rcu() for deferred free while the dst uses synchronous reference counting via dst_clone()/dst_release()—these are independent synchronization domains. When the writer path defers the struct free but synchronously releases the dst, it creates a window where a concurrent reader holding a stale params pointer attempts to clone a dst already in RCUREF_DEAD state. The KASAN trace confirms a write to freed dst during skb processing—packets were in flight during a rule update. This is the third instance of the same anti-pattern in the networking subsystem: CVE-2019-14895 in vhost_net, CVE-2020-1749 in vxlan, and now this. Each fix is technically correct; none encode the anti-pattern. The kernel's API offers zero friction—kfree_rcu() and dst_release() look like equivalent-level cleanup primitives but occupy non-composable synchronization domains. No compiler warning flags this combination. Practically: audit every act_* module with embedded dst or similar reference-counted resources for the same deferred-struct-free plus synchronous-embedded-release pattern. The flow_offload infrastructure calling tcf_action_offload_add_ex is a high-priority target—this module sits at the datapath/controlpath intersection, meaning ordinary traffic coinciding with admin operations triggers the race. The corruption propagates through skb->dst to both drivers and TCP congestion control decisions, creating failure surfaces the CVSS score doesn't capture. Prioritize fixes in high-reach modules over low-frequency paths with identical severity scores—exposure isn't uniform.

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