<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 21:48:45 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-23016 — inet: frags: drop fraglist conntrack references</title>
      <link>https://db.gcve.eu/vuln/cve-2026-23016</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;inet: frags: drop fraglist conntrack references&lt;/p&gt;
&lt;p&gt;Jakub added a warning in nf_conntrack_cleanup_net_list() to make debugging
leaked skbs/conntrack references more obvious.&lt;/p&gt;
&lt;p&gt;syzbot reports this as triggering, and I can also reproduce this via
ip_defrag.sh selftest:&lt;/p&gt;
&lt;p&gt;conntrack cleanup blocked for 60s
 WARNING: net/netfilter/nf_conntrack_core.c:2512
 [..]&lt;/p&gt;
&lt;p&gt;conntrack clenups gets stuck because there are skbs with still hold nf_conn
references via their frag_list.&lt;/p&gt;
&lt;p&gt;net.core.skb_defer_max=0 makes the hang disappear.&lt;/p&gt;
&lt;p&gt;Eric Dumazet points out that skb_release_head_state() doesn&amp;#39;t follow the
fraglist.&lt;/p&gt;
&lt;p&gt;ip_defrag.sh can only reproduce this problem since
commit 6471658dc66c (&amp;#34;udp: use skb_attempt_defer_free()&amp;#34;), but AFAICS this
problem could happen with TCP as well if pmtu discovery is off.&lt;/p&gt;
&lt;p&gt;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-&amp;gt;nf_conn attached
7. skbs are reassembled via ipv6_frag_rcv()
8. skb_consume_udp -&amp;gt; skb_attempt_defer_free() -&amp;gt; skb ends up
   in pcpu freelist, but still has nf_conn reference.&lt;/p&gt;
&lt;p&gt;Possible solutions:
 1 let defrag engine drop nf_conn en…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;inet: frags: drop fraglist conntrack references&lt;/p&gt;
&lt;p&gt;Jakub added a warning in nf_conntrack_cleanup_net_list() to make debugging
leaked skbs/conntrack references more obvious.&lt;/p&gt;
&lt;p&gt;syzbot reports this as triggering, and I can also reproduce this via
ip_defrag.sh selftest:&lt;/p&gt;
&lt;p&gt;conntrack cleanup blocked for 60s
 WARNING: net/netfilter/nf_conntrack_core.c:2512
 [..]&lt;/p&gt;
&lt;p&gt;conntrack clenups gets stuck because there are skbs with still hold nf_conn
references via their frag_list.&lt;/p&gt;
&lt;p&gt;net.core.skb_defer_max=0 makes the hang disappear.&lt;/p&gt;
&lt;p&gt;Eric Dumazet points out that skb_release_head_state() doesn&amp;#39;t follow the
fraglist.&lt;/p&gt;
&lt;p&gt;ip_defrag.sh can only reproduce this problem since
commit 6471658dc66c (&amp;#34;udp: use skb_attempt_defer_free()&amp;#34;), but AFAICS this
problem could happen with TCP as well if pmtu discovery is off.&lt;/p&gt;
&lt;p&gt;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-&amp;gt;nf_conn attached
7. skbs are reassembled via ipv6_frag_rcv()
8. skb_consume_udp -&amp;gt; skb_attempt_defer_free() -&amp;gt; skb ends up
   in pcpu freelist, but still has nf_conn reference.&lt;/p&gt;
&lt;p&gt;Possible solutions:
 1 let defrag engine drop nf_conn en…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-23016</guid>
    </item>
  </channel>
</rss>
