CVE-2026-23016
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2026-01-31

Last updated on: 2026-03-25

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: inet: frags: drop fraglist conntrack references Jakub added a warning in nf_conntrack_cleanup_net_list() to make debugging leaked skbs/conntrack references more obvious. syzbot reports this as triggering, and I can also reproduce this via ip_defrag.sh selftest: conntrack cleanup blocked for 60s WARNING: net/netfilter/nf_conntrack_core.c:2512 [..] conntrack clenups gets stuck because there are skbs with still hold nf_conn references via their frag_list. net.core.skb_defer_max=0 makes the hang disappear. Eric Dumazet points out that skb_release_head_state() doesn't follow the fraglist. ip_defrag.sh can only reproduce this problem since commit 6471658dc66c ("udp: use skb_attempt_defer_free()"), but AFAICS this problem could happen with TCP as well if pmtu discovery is off. The relevant problem path for udp is: 1. netns emits fragmented packets 2. nf_defrag_v6_hook reassembles them (in output hook) 3. reassembled skb is tracked (skb owns nf_conn reference) 4. ip6_output refragments 5. refragmented packets also own nf_conn reference (ip6_fragment calls ip6_copy_metadata()) 6. on input path, nf_defrag_v6_hook skips defragmentation: the fragments already have skb->nf_conn attached 7. skbs are reassembled via ipv6_frag_rcv() 8. skb_consume_udp -> skb_attempt_defer_free() -> skb ends up in pcpu freelist, but still has nf_conn reference. Possible solutions: 1 let defrag engine drop nf_conn entry, OR 2 export kick_defer_list_purge() and call it from the conntrack netns exit callback, OR 3 add skb_has_frag_list() check to skb_attempt_defer_free() 2 & 3 also solve ip_defrag.sh hang but share same drawback: Such reassembled skbs, queued to socket, can prevent conntrack module removal until userspace has consumed the packet. While both tcp and udp stack do call nf_reset_ct() before placing skb on socket queue, that function doesn't iterate frag_list skbs. Therefore drop nf_conn entries when they are placed in defrag queue. Keep the nf_conn entry of the first (offset 0) skb so that reassembled skb retains nf_conn entry for sake of TX path. Note that fixes tag is incorrect; it points to the commit introducing the 'ip_defrag.sh reproducible problem': no need to backport this patch to every stable kernel.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-01-31
Last Modified
2026-03-25
Generated
2026-05-07
AI Q&A
2026-01-31
EPSS Evaluated
2026-05-05
NVD
CVE-2026-23016
EUVD
EUVD-2026-5078
Affected Vendors & Products
Showing 10 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.18
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 6.18.1 (inc) to 6.18.6 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel involves the handling of fragmented network packets and their associated connection tracking (conntrack) references. Specifically, when fragmented packets are reassembled and then refragmented, the skbs (socket buffers) retain nf_conn (connection tracking) references via their frag_list. This causes conntrack cleanup to get stuck or hang because these references are not properly released. The issue arises because the skb_release_head_state() function does not follow the fraglist to release these references, leading to leaked conntrack references and potential hangs during cleanup.


How can this vulnerability impact me? :

This vulnerability can cause the conntrack cleanup process in the Linux kernel to hang or get blocked for extended periods (e.g., 60 seconds), potentially leading to resource leaks and system instability. It can also prevent the removal of the conntrack module until userspace has consumed the affected packets, which may impact network performance and reliability, especially in environments handling fragmented UDP or TCP packets with Path MTU discovery disabled.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing warnings related to conntrack cleanup being blocked, such as the message: 'conntrack cleanup blocked for 60s' and warnings in net/netfilter/nf_conntrack_core.c. The ip_defrag.sh selftest script can reproduce the problem. Additionally, setting the kernel parameter net.core.skb_defer_max=0 can make the hang disappear, which can be used as a diagnostic step.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include setting the kernel parameter net.core.skb_defer_max=0 to avoid the hang caused by skb deferral. Also, applying fixes that drop nf_conn entries when skbs are placed in the defrag queue can help. These fixes involve letting the defrag engine drop nf_conn entries, calling kick_defer_list_purge() from the conntrack netns exit callback, or adding skb_has_frag_list() checks to skb_attempt_defer_free().


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart