<?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://cve.radiocsirt.org</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>Thu, 08 Oct 2026 03:24:18 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-04135</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-04135</link>
      <description>bdu:2026-04135</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-04135</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-23016</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-23016</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-23016</guid>
    </item>
    <item>
      <title>EUVD-2026-315291</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-315291</link>
      <description>EUVD-2026-315291</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-315291</guid>
    </item>
    <item>
      <title>fkie_cve-2026-23016</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-23016</link>
      <description>&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;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://cve.radiocsirt.org/vuln/fkie_cve-2026-23016</guid>
    </item>
    <item>
      <title>GHSA-8h8q-4wvg-mhgm</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-8h8q-4wvg-mhgm</link>
      <description>&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;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://cve.radiocsirt.org/vuln/ghsa-8h8q-4wvg-mhgm</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-23016</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23016</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 81 more&lt;/p&gt;
&lt;p&gt;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&amp;#39;t follow the fraglist. 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. 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. Possible solutions:  1 let defrag engine drop nf_conn entry, OR  2…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 81 more&lt;/p&gt;
&lt;p&gt;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&amp;#39;t follow the fraglist. 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. 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. Possible solutions:  1 let defrag engine drop nf_conn entry, OR  2…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23016</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-0280 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0280</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0280</guid>
    </item>
  </channel>
</rss>
