<?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>Mon, 05 Oct 2026 09:11:43 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-10554</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-10554</link>
      <description>bdu:2026-10554</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-10554</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-68169</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-68169</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-2025-68169</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0169 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0169</link>
      <description>certfr-2026-avi-0169</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0169</guid>
    </item>
    <item>
      <title>CLEANSTART-2026-GH39701 — Security fix for CVE-2025-68169 applied in: openssl 3.6.0-r0</title>
      <link>https://cve.radiocsirt.org/vuln/cleanstart-2026-gh39701</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: openssl&lt;/p&gt;
&lt;p&gt;Security vulnerability affects the openssl package. This issue is resolved in later releases. See references for vulnerability details.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: openssl&lt;/p&gt;
&lt;p&gt;Security vulnerability affects the openssl package. This issue is resolved in later releases. See references for vulnerability details.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cleanstart-2026-gh39701</guid>
    </item>
    <item>
      <title>EUVD-2026-315031</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-315031</link>
      <description>EUVD-2026-315031</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-315031</guid>
    </item>
    <item>
      <title>fkie_cve-2025-68169</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-68169</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netpoll: Fix deadlock in memory allocation under spinlock&lt;/p&gt;
&lt;p&gt;Fix a AA deadlock in refill_skbs() where memory allocation while holding
skb_pool-&amp;gt;lock can trigger a recursive lock acquisition attempt.&lt;/p&gt;
&lt;p&gt;The deadlock scenario occurs when the system is under severe memory
pressure:&lt;/p&gt;
&lt;p&gt;1. refill_skbs() acquires skb_pool-&amp;gt;lock (spinlock)
2. alloc_skb() is called while holding the lock
3. Memory allocator fails and calls slab_out_of_memory()
4. This triggers printk() for the OOM warning
5. The console output path calls netpoll_send_udp()
6. netpoll_send_udp() attempts to acquire the same skb_pool-&amp;gt;lock
7. Deadlock: the lock is already held by the same CPU&lt;/p&gt;
&lt;p&gt;Call stack:
  refill_skbs()
    spin_lock_irqsave(&amp;amp;skb_pool-&amp;gt;lock)    &amp;lt;- lock acquired
    __alloc_skb()
      kmem_cache_alloc_node_noprof()
        slab_out_of_memory()
          printk()
            console_flush_all()
              netpoll_send_udp()
                skb_dequeue()
                  spin_lock_irqsave(&amp;amp;skb_pool-&amp;gt;lock)     &amp;lt;- deadlock attempt&lt;/p&gt;
&lt;p&gt;This bug was exposed by commit 248f6571fd4c51 (&amp;#34;netpoll: Optimize skb
refilling on critical path&amp;#34;) which removed refill_skbs() from the
critical path (where nested printk was being deferred), letting nested
printk being called from inside refill_skbs()&lt;/p&gt;
&lt;p&gt;Refactor refill_skbs() to never allocate memory while holding
the spinlock.&lt;/p&gt;
&lt;p&gt;Another possible solution to fix this problem is protecting the
refill_skbs() from…&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;netpoll: Fix deadlock in memory allocation under spinlock&lt;/p&gt;
&lt;p&gt;Fix a AA deadlock in refill_skbs() where memory allocation while holding
skb_pool-&amp;gt;lock can trigger a recursive lock acquisition attempt.&lt;/p&gt;
&lt;p&gt;The deadlock scenario occurs when the system is under severe memory
pressure:&lt;/p&gt;
&lt;p&gt;1. refill_skbs() acquires skb_pool-&amp;gt;lock (spinlock)
2. alloc_skb() is called while holding the lock
3. Memory allocator fails and calls slab_out_of_memory()
4. This triggers printk() for the OOM warning
5. The console output path calls netpoll_send_udp()
6. netpoll_send_udp() attempts to acquire the same skb_pool-&amp;gt;lock
7. Deadlock: the lock is already held by the same CPU&lt;/p&gt;
&lt;p&gt;Call stack:
  refill_skbs()
    spin_lock_irqsave(&amp;amp;skb_pool-&amp;gt;lock)    &amp;lt;- lock acquired
    __alloc_skb()
      kmem_cache_alloc_node_noprof()
        slab_out_of_memory()
          printk()
            console_flush_all()
              netpoll_send_udp()
                skb_dequeue()
                  spin_lock_irqsave(&amp;amp;skb_pool-&amp;gt;lock)     &amp;lt;- deadlock attempt&lt;/p&gt;
&lt;p&gt;This bug was exposed by commit 248f6571fd4c51 (&amp;#34;netpoll: Optimize skb
refilling on critical path&amp;#34;) which removed refill_skbs() from the
critical path (where nested printk was being deferred), letting nested
printk being called from inside refill_skbs()&lt;/p&gt;
&lt;p&gt;Refactor refill_skbs() to never allocate memory while holding
the spinlock.&lt;/p&gt;
&lt;p&gt;Another possible solution to fix this problem is protecting the
refill_skbs() from…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-68169</guid>
    </item>
    <item>
      <title>GHSA-x9w7-p4vp-q593</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-x9w7-p4vp-q593</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netpoll: Fix deadlock in memory allocation under spinlock&lt;/p&gt;
&lt;p&gt;Fix a AA deadlock in refill_skbs() where memory allocation while holding
skb_pool-&amp;gt;lock can trigger a recursive lock acquisition attempt.&lt;/p&gt;
&lt;p&gt;The deadlock scenario occurs when the system is under severe memory
pressure:&lt;/p&gt;
&lt;p&gt;1. refill_skbs() acquires skb_pool-&amp;gt;lock (spinlock)
2. alloc_skb() is called while holding the lock
3. Memory allocator fails and calls slab_out_of_memory()
4. This triggers printk() for the OOM warning
5. The console output path calls netpoll_send_udp()
6. netpoll_send_udp() attempts to acquire the same skb_pool-&amp;gt;lock
7. Deadlock: the lock is already held by the same CPU&lt;/p&gt;
&lt;p&gt;Call stack:
  refill_skbs()
    spin_lock_irqsave(&amp;amp;skb_pool-&amp;gt;lock)    &amp;lt;- lock acquired
    __alloc_skb()
      kmem_cache_alloc_node_noprof()
        slab_out_of_memory()
          printk()
            console_flush_all()
              netpoll_send_udp()
                skb_dequeue()
                  spin_lock_irqsave(&amp;amp;skb_pool-&amp;gt;lock)     &amp;lt;- deadlock attempt&lt;/p&gt;
&lt;p&gt;This bug was exposed by commit 248f6571fd4c51 (&amp;#34;netpoll: Optimize skb
refilling on critical path&amp;#34;) which removed refill_skbs() from the
critical path (where nested printk was being deferred), letting nested
printk being called from inside refill_skbs()&lt;/p&gt;
&lt;p&gt;Refactor refill_skbs() to never allocate memory while holding
the spinlock.&lt;/p&gt;
&lt;p&gt;Another possible solution to fix this problem is protecting the
refill_skbs() from…&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;netpoll: Fix deadlock in memory allocation under spinlock&lt;/p&gt;
&lt;p&gt;Fix a AA deadlock in refill_skbs() where memory allocation while holding
skb_pool-&amp;gt;lock can trigger a recursive lock acquisition attempt.&lt;/p&gt;
&lt;p&gt;The deadlock scenario occurs when the system is under severe memory
pressure:&lt;/p&gt;
&lt;p&gt;1. refill_skbs() acquires skb_pool-&amp;gt;lock (spinlock)
2. alloc_skb() is called while holding the lock
3. Memory allocator fails and calls slab_out_of_memory()
4. This triggers printk() for the OOM warning
5. The console output path calls netpoll_send_udp()
6. netpoll_send_udp() attempts to acquire the same skb_pool-&amp;gt;lock
7. Deadlock: the lock is already held by the same CPU&lt;/p&gt;
&lt;p&gt;Call stack:
  refill_skbs()
    spin_lock_irqsave(&amp;amp;skb_pool-&amp;gt;lock)    &amp;lt;- lock acquired
    __alloc_skb()
      kmem_cache_alloc_node_noprof()
        slab_out_of_memory()
          printk()
            console_flush_all()
              netpoll_send_udp()
                skb_dequeue()
                  spin_lock_irqsave(&amp;amp;skb_pool-&amp;gt;lock)     &amp;lt;- deadlock attempt&lt;/p&gt;
&lt;p&gt;This bug was exposed by commit 248f6571fd4c51 (&amp;#34;netpoll: Optimize skb
refilling on critical path&amp;#34;) which removed refill_skbs() from the
critical path (where nested printk was being deferred), letting nested
printk being called from inside refill_skbs()&lt;/p&gt;
&lt;p&gt;Refactor refill_skbs() to never allocate memory while holding
the spinlock.&lt;/p&gt;
&lt;p&gt;Another possible solution to fix this problem is protecting the
refill_skbs() from…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-x9w7-p4vp-q593</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-68169</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68169</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 94 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: netpoll: Fix deadlock in memory allocation under spinlock Fix a AA deadlock in refill_skbs() where memory allocation while holding skb_pool-&amp;gt;lock can trigger a recursive lock acquisition attempt. The deadlock scenario occurs when the system is under severe memory pressure: 1. refill_skbs() acquires skb_pool-&amp;gt;lock (spinlock) 2. alloc_skb() is called while holding the lock 3. Memory allocator fails and calls slab_out_of_memory() 4. This triggers printk() for the OOM warning 5. The console output path calls netpoll_send_udp() 6. netpoll_send_udp() attempts to acquire the same skb_pool-&amp;gt;lock 7. Deadlock: the lock is already held by the same CPU Call stack:   refill_skbs()     spin_lock_irqsave(&amp;amp;skb_pool-&amp;gt;lock)    &amp;lt;- lock acquired     __alloc_skb()       kmem_cache_alloc_node_noprof()         slab_out_of_memory()           printk()             console_flush_all()               netpoll_send_udp()                 skb_dequeue()                   spin_lock_irqsave(&amp;amp;skb_pool-&amp;gt;lock)     &amp;lt;- deadlock attempt This bug was exposed by commit 248f6571fd4c51 (&amp;#34;netpoll: Optimize skb refilling on critical path&amp;#34;) which removed refill_skbs() from the critical path (where nested printk was being deferred), letting nested printk being called from inside refill_skbs() Refactor refill_skbs() to never allocate memory while holding the spinlock. Another possible solution to fix this problem is protecting the refill_skbs() from nested p…&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 94 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: netpoll: Fix deadlock in memory allocation under spinlock Fix a AA deadlock in refill_skbs() where memory allocation while holding skb_pool-&amp;gt;lock can trigger a recursive lock acquisition attempt. The deadlock scenario occurs when the system is under severe memory pressure: 1. refill_skbs() acquires skb_pool-&amp;gt;lock (spinlock) 2. alloc_skb() is called while holding the lock 3. Memory allocator fails and calls slab_out_of_memory() 4. This triggers printk() for the OOM warning 5. The console output path calls netpoll_send_udp() 6. netpoll_send_udp() attempts to acquire the same skb_pool-&amp;gt;lock 7. Deadlock: the lock is already held by the same CPU Call stack:   refill_skbs()     spin_lock_irqsave(&amp;amp;skb_pool-&amp;gt;lock)    &amp;lt;- lock acquired     __alloc_skb()       kmem_cache_alloc_node_noprof()         slab_out_of_memory()           printk()             console_flush_all()               netpoll_send_udp()                 skb_dequeue()                   spin_lock_irqsave(&amp;amp;skb_pool-&amp;gt;lock)     &amp;lt;- deadlock attempt This bug was exposed by commit 248f6571fd4c51 (&amp;#34;netpoll: Optimize skb refilling on critical path&amp;#34;) which removed refill_skbs() from the critical path (where nested printk was being deferred), letting nested printk being called from inside refill_skbs() Refactor refill_skbs() to never allocate memory while holding the spinlock. Another possible solution to fix this problem is protecting the refill_skbs() from nested p…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-68169</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2868 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2868</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-2025-2868</guid>
    </item>
  </channel>
</rss>
