CVE-2026-74695 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_flow_table: drop existing skb dst before skb_dst_set_noref()
Incoming skbs passing through netfilter flowtable offload hooks (or XFRM offload path) might already carry a ref-counted dst_entry assigned during earlier RX or routing steps.
Calling skb_dst_set_noref() when skb already holds a ref-counted dst overwrites skb->_skb_refdst, leaking the previous dst_entry reference count and triggering a DEBUG_NET_WARN_ON_ONCE assertion in skb_dst_check_unset():
WARNING: at skb_dst_check_unset include/linux/skbuff.h:1170 WARNING: at skb_dst_set_noref include/linux/skbuff.h:1234 WARNING: at nf_flow_offload_ip_hook+0xf6c/0x2b60 net/netfilter/nf_flow_table_ip.c:864
Drop any existing dst_entry reference with skb_dst_drop(skb) before setting the non-referenced flowtable destination.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel vulnerability identified in the netfilter subsystem, specifically within the nf_flow_table module, represents a critical resource management flaw involving socket buffer descriptor handling during network packet processing. This issue arises when incoming packets traverse through netfilter flow table offload hooks or the XFRM (IPsec) offload path. In these scenarios, the kernel's networking stack may have already assigned a reference-counted dst_entry to the sk_buff structure during earlier receive or routing operations. The core technical flaw lies in the subsequent handling of this descriptor by the nf_flow_table code, which attempts to set a new destination entry using skb_dst_set_noref without first releasing the existing reference. This function is designed for cases where no additional reference count increment is needed, but it fails to account for an already held reference on the previous dst_entry object.
The operational consequence of this oversight is a memory leak and potential system instability due to incorrect reference counting mechanics within the kernel networking stack. When skb_dst_set_noref overwrites the _skb_refdst field without prior cleanup, the original dst_entry loses its connection to the socket buffer while retaining an active reference count that is never decremented. This discrepancy triggers internal debugging assertions such as DEBUG_NET_WARN_ON_ONCE in functions like skb_dst_check_unset and nf_flow_offload_ip_hook. These warnings indicate a violation of kernel memory safety protocols, where objects are allocated but not properly freed upon being replaced or discarded. Over time, this can lead to significant memory exhaustion, degraded network performance due to resource contention, and potentially a denial of service condition if the leak rate is high enough under heavy traffic loads.
From a classification perspective, this vulnerability aligns with CWE-401, which describes missing release of memory after effective usage, as well as CWE-755, relating to improper handling of unusual or exceptional input conditions where pre-existing state is not correctly managed before modification. In the context of the MITRE ATT&CK framework for enterprise security, this flaw could be leveraged in conjunction with other techniques to cause resource exhaustion, contributing to availability impact categories such as T1498 Network Denial of Service. The vulnerability highlights a common pitfall in low-level network programming where assumptions about object lifecycle and reference counts are not rigorously validated against all execution paths.
To mitigate this risk, the primary remediation involves modifying the nf_flow_table_ip.c source code to explicitly drop any existing dst_entry reference before assigning the new non-referenced destination. This is achieved by invoking skb_dst_drop on the sk_buff structure prior to calling skb_dst_set_noref. This ensures that the previous routing or receive path's reference count is correctly decremented, preventing the leak and maintaining kernel stability. System administrators should apply the latest available kernel patches that include this fix immediately. Furthermore, organizations operating Linux-based infrastructure should monitor for related warning logs in system dmesg outputs to detect any instances where this condition might have triggered prior to patching, allowing for proactive assessment of potential resource consumption anomalies.