CVE-2025-68169
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-12-16

Last updated on: 2025-12-18

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-16
Last Modified
2025-12-18
Generated
2026-05-07
AI Q&A
2025-12-16
EPSS Evaluated
2026-05-05
NVD
CVE-2025-68169
EUVD
EUVD-2025-203727
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a deadlock in the Linux kernel's netpoll subsystem caused by memory allocation while holding a spinlock. Specifically, in the refill_skbs() function, the code acquires a spinlock and then attempts to allocate memory. If the system is under severe memory pressure, the memory allocator fails and triggers an out-of-memory warning via printk(). The printk() call leads to a console output path that tries to send a UDP packet using netpoll_send_udp(), which attempts to acquire the same spinlock already held by the current CPU, causing a deadlock. The fix involves refactoring refill_skbs() to avoid allocating memory while holding the spinlock, preventing this recursive lock acquisition and deadlock.


How can this vulnerability impact me? :

This vulnerability can cause the system to deadlock under severe memory pressure conditions, specifically when the netpoll subsystem tries to allocate memory while holding a spinlock. This deadlock can halt certain kernel operations related to network packet handling and console output, potentially leading to system instability or unresponsiveness.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update the Linux kernel to a version where the netpoll deadlock issue in refill_skbs() has been fixed. The fix involves refactoring refill_skbs() to avoid memory allocation while holding the spinlock, preventing the deadlock scenario. Alternatively, applying patches that protect refill_skbs() from nested printk calls by deferring them can also mitigate the issue. Avoid running kernels with the vulnerable commit (248f6571fd4c51) and monitor for kernel updates addressing this problem.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart