CVE-2026-23016: inet: frags: drop fraglist conntrack references
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.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel networking bug where fragmented packet handling can leave connection-tracking references behind. The documented impact is a blocked conntrack cleanup path and potential hang during network namespace or conntrack cleanup, not confirmed remote code execution or data theft.
Executive priority
Patch through the normal kernel maintenance cycle, with higher priority for infrastructure relying on conntrack or network namespaces. There is no cited evidence of active exploitation, but cleanup hangs in core networking can create operational risk.
Technical view
The issue involves inet fragment reassembly, frag_list skb handling, and nf_conntrack references. Reassembled and refragmented packets can retain nf_conn references on frag_list skbs because cleanup does not walk the fraglist. The kernel fix drops conntrack references when skbs enter the defrag queue while preserving the first skb reference for TX behavior.
Likely exposure
Exposure is limited to affected Linux kernel versions identified in the CVE data, notably the 6.18 to 6.19 range, especially systems using netfilter conntrack with fragmented IPv6 or related UDP/TCP traffic paths. Distribution backports may change exact exposure.
Exploitation context
No KEV listing or cited source reports active exploitation. The evidence describes syzbot and kernel selftest reproduction of cleanup blockage. Treat this as a reliability and denial-of-service concern until vendor advisories provide clearer impact scoring.
Researcher notes
The CVE text states the fixes tag is not a broad backport signal. Validate against vendor-patched kernels, not only upstream version numbers. The described reproducible path is UDP over IPv6 fragmentation, but the source notes TCP may also be possible under specific conditions.
Mitigation direction
Apply a vendor kernel update containing the referenced stable fixes.
Check distribution advisories for exact affected and fixed package versions.
Prioritize hosts using conntrack, netfilter, network namespaces, or fragmented traffic paths.
Avoid treating sysctl observations as a permanent fix unless vendor guidance confirms it.
Validation and detection
Inventory Linux kernel versions across servers, appliances, and container hosts.
Check whether deployed kernels include either referenced stable commit.
Review conntrack, netfilter, and IPv6 fragmentation usage on affected systems.
Monitor for conntrack cleanup stalls or related kernel warnings.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23016 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
3Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jan 31, 2026, 11:38 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.