<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-03T21:48:45.379402+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/cve-2026-23016</id>
    <title>CVE-2026-23016 — inet: frags: drop fraglist conntrack references</title>
    <updated>2026-10-03T21:48:45.394584+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>inet: frags: drop fraglist conntrack references</p>
<p>Jakub added a warning in nf_conntrack_cleanup_net_list() to make debugging
leaked skbs/conntrack references more obvious.</p>
<p>syzbot reports this as triggering, and I can also reproduce this via
ip_defrag.sh selftest:</p>
<p>conntrack cleanup blocked for 60s
 WARNING: net/netfilter/nf_conntrack_core.c:2512
 [..]</p>
<p>conntrack clenups gets stuck because there are skbs with still hold nf_conn
references via their frag_list.</p>
<p>net.core.skb_defer_max=0 makes the hang disappear.</p>
<p>Eric Dumazet points out that skb_release_head_state() doesn't follow the
fraglist.</p>
<p>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.</p>
<p>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-&gt;nf_conn attached
7. skbs are reassembled via ipv6_frag_rcv()
8. skb_consume_udp -&gt; skb_attempt_defer_free() -&gt; skb ends up
   in pcpu freelist, but still has nf_conn reference.</p>
<p>Possible solutions:
 1 let defrag engine drop nf_conn en…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-23016"/>
  </entry>
</feed>
