<?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://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T13:57:14.330983+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" 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://vulnerability.circl.lu/vuln/cve-2025-68169</id>
    <title>CVE-2025-68169 — netpoll: Fix deadlock in memory allocation under spinlock</title>
    <updated>2026-09-30T13:57:15.193644+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>netpoll: Fix deadlock in memory allocation under spinlock</p>
<p>Fix a AA deadlock in refill_skbs() where memory allocation while holding
skb_pool-&gt;lock can trigger a recursive lock acquisition attempt.</p>
<p>The deadlock scenario occurs when the system is under severe memory
pressure:</p>
<p>1. refill_skbs() acquires skb_pool-&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-&gt;lock
7. Deadlock: the lock is already held by the same CPU</p>
<p>Call stack:
  refill_skbs()
    spin_lock_irqsave(&amp;skb_pool-&gt;lock)    &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;skb_pool-&gt;lock)     &lt;- deadlock attempt</p>
<p>This bug was exposed by commit 248f6571fd4c51 ("netpoll: Optimize skb
refilling on critical path") which removed refill_skbs() from the
critical path (where nested printk was being deferred), letting nested
printk being called from inside refill_skbs()</p>
<p>Refactor refill_skbs() to never allocate memory while holding
the spinlock.</p>
<p>Another possible solution to fix this problem is protecting the
refill_skbs() from…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2025-68169"/>
  </entry>
</feed>
