# CVE-2025-68169: netpoll: Fix deadlock in memory allocation under spinlock

> A deadlock in the Linux kernel netpoll subsystem can cause a system hang when memory allocation fails under pressure, leading to denial of service.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 16 Dec 2025
- **Updated:** 11 May 2026
- **Also known as:** BELL-CVE-2025-68169, CLEANSTART-2026-GH39701, DEBIAN-CVE-2025-68169, GHSA-x9w7-p4vp-q593, UBUNTU-CVE-2025-68169

## What is CVE-2025-68169?

CVE-2025-68169 is a denial of service vulnerability in Linux, published on 16 Dec 2025. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

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->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->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->lock
7. Deadlock: the lock is already held by the same CPU

Call stack:
  refill_skbs()
    spin_lock_irqsave(&skb_pool->lock)    <- 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(&skb_pool->lock)     <- deadlock attempt

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()

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 printks, basically calling
printk_deferred_{enter,exit}() in refill_skbs(), then, any nested
pr_warn() would be deferred.

I prefer this approach, given I _think_ it might be a good idea to move
the alloc_skb() from GFP_ATOMIC to GFP_KERNEL in the future, so, having
the alloc_skb() outside of the lock will be necessary step.

There is a possible TOCTOU issue when checking for the pool length, and
queueing the new allocated skb, but, this is not an issue, given that
an extra SKB in the pool is harmless and it will be eventually used.

## Which versions are affected by CVE-2025-68169?


## How do I fix CVE-2025-68169?

Apply the vendor's patch.

## Is CVE-2025-68169 being exploited?

There is no known exploitation of CVE-2025-68169 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2025-68169 and fix it if it is affected.

What it is: CVE-2025-68169 is a denial of service vulnerability in Linux, published on 16 Dec 2025. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2025-68169 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2025-68169/ (Markdown: https://insights.sbomify.com/CVE-2025-68169/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2025-68169
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-68169
- OSV: https://osv.dev/vulnerability/CVE-2025-68169

---
From sbomify Insights: https://insights.sbomify.com/CVE-2025-68169/
Summaries are generated and may contain mistakes; the official description above is the record.