CVE-2026-74695: netfilter: nf_flow_table: drop existing skb dst before skb_dst_set_noref()
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfflowtable: drop existing skb dst before skbdstsetnoref()
Incoming skbs passing through netfilter flowtable offload hooks (or XFRM offload path) might already carry a ref-counted dstentry assigned during earlier RX or routing steps.
Calling skbdstsetnoref() when skb already holds a ref-counted dst overwrites skb->skbrefdst, leaking the previous dstentry reference count and triggering a DEBUGNETWARNONONCE assertion in skbdstcheckunset():
WARNING: at skbdstcheckunset include/linux/skbuff.h:1170 WARNING: at skbdstsetnoref include/linux/skbuff.h:1234 WARNING: at nfflowoffloadiphook+0xf6c/0x2b60 net/netfilter/nfflowtableip.c:864
Drop any existing dstentry reference with skbdstdrop(skb) before setting the non-referenced flowtable destination.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Before calling skb_dst_set_noref() when skb already holds a ref-counted dst_entry, drop the existing dst_entry reference by calling skb_dst_drop(skb) to avoid leaking the previous dst_entry reference.
Linux kernel netfilter flowtable offload skb->_skb_refdst dst_entry handling = Drop existing dst_entry with skb_dst_drop(skb) before calling skb_dst_set_noref()
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems whose incoming packets traverse netfilter flowtable offload hooks or the XFRM offload path may be exposed, particularly when those packets already carry a ref-counted dst_entry from earlier receive or routing processing.
What does triggering the flaw require?
A packet must reach the affected flowtable or XFRM offload processing path with an existing ref-counted destination entry. The vulnerable handling overwrites that destination state with a non-referenced flowtable destination without first releasing the prior reference.
How can I identify signs of exposure?
With kernel debug checks enabled, affected processing can produce a DEBUG_NET_WARN_ON_ONCE assertion in skb_dst_check_unset(), with warnings referencing skb_dst_set_noref() and nf_flow_offload_ip_hook. The condition also leaks the previous dst_entry reference count.
What mitigation is indicated by the available information?
Apply a kernel update containing the fix that calls skb_dst_drop(skb) before assigning the non-referenced flowtable destination. The provided data does not specify a configuration-only workaround.