In the Linux kernel, the following vulnerability has been resolved:
inet: frags: drop fraglist conntrack references
Jakub added a warning in nfconntrackcleanupnetlist() 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/nfconntrackcore.c:2512 [..]
conntrack clenups gets stuck because there are skbs with still hold nfconn references via their fraglist.
net.core.skbdefermax=0 makes the hang disappear.
Eric Dumazet points out that skbreleasehead_state() doesn't follow the fraglist.
ipdefrag.sh can only reproduce this problem since commit 6471658dc66c ("udp: use skbattemptdeferfree()"), 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. nfdefragv6hook reassembles them (in output hook) 3. reassembled skb is tracked (skb owns nfconn reference) 4. ip6output refragments 5. refragmented packets also own nfconn reference (ip6fragment calls ip6copymetadata()) 6. on input path, nfdefragv6hook skips defragmentation: the fragments already have skb->nfconn attached 7. skbs are reassembled via ipv6fragrcv() 8. skbconsumeudp -> skbattemptdeferfree() -> skb ends up in pcpu freelist, but still has nf_conn reference.
Possible solutions: 1 let defrag engine drop nfconn entry, OR 2 export kickdeferlistpurge() and call it from the conntrack netns exit callback, OR 3 add skbhasfraglist() check to skbattemptdeferfree()
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 nfresetct() before placing skb on socket queue, that function doesn't iterate frag_list skbs.
Therefore drop nfconn entries when they are placed in defrag queue. Keep the nfconn 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.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/23xxx/CVE-2026-23016.json"
}