CVE-2026-23016 Details
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.
A vulnerability in the Linux kernel's handling of fragmented packets can lead to a conntrack reference leak, causing network namespace cleanup to hang. This issue arises when fragmented IPv6 packets are reassembled and tracked by the conntrack module, but the reassembled packets are not properly defragmented before being processed, leaving dangling references that can block module removal. The problem has been reproduced using the 'ip_defrag.sh' self-test, and is present in the stable Linux kernel.
No specific remediation is provided, but the issue can be addressed by managing the conntrack references more effectively during the defragmentation process.
Metrics
CVSS 4.0 Severity and Vector Strings:
No CVSS 4.0 data is available for this CVE.
CVSS 3.x Severity and Vector Strings:
No data available for CVSS Version 2.0 on this CVE.
No SSVC data is available for this CVE.
References to Advisories, Solutions, and Tools
By selecting these links, you will be leaving this site. These are references gathered from the official CVE record and are not endorsed by Volerion.
| URL | Source(s) | Tag(s) |
|---|---|---|
| https://git.kernel.org/stable/c/088ca99dbb039c444c3ff987c5412a73f4f0cbf8 | kernel.org | Patch |
| https://git.kernel.org/stable/c/2ef02ac38d3c17f34a00c4b267d961a8d4b45d1a | kernel.org | Patch |
Weakness Enumeration
| CWE-ID | CWE Name | Source |
|---|---|---|
| NVD-CWE-Other | Weakness Not in a Standard CWE Category | [email protected] |
Affected Products
| Product | Versions |
|---|---|
| linux linux kernel | >= 6.18.1, < 6.18.6 6.18 - 6.19 rc1 6.19 rc2 6.19 rc3 6.19 rc4 6.19 rc5 6.19 rc6 6.19 rc7 6.19 rc8 |
CPE
Remediation
| |
Change History
3 change records found show changes
| Date | Action | Recorded By |
|---|---|---|
| Jun 17, 2026 | CVE Modified | kernel.org |
| Mar 25, 2026 | Initial Analysis | [email protected] |
| Jan 31, 2026 | New CVE Received | kernel.org |