The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2025-68169)

Note that Nessus relies on the presence of the package as reported by the vendor.

Detections

Analytics

Linux Distros Unpatched Vulnerability : CVE-2025-68169

medium Nessus Plugin ID 279006

Version 1.6

Version 1.5

Version 1.3

Version 1.2

Version 1.1

Version 1.6 Feb 14, 2026, 1:12 AM Detection (updated detection logic) Plugin Feed: 202602140112
Version 1.5 Feb 4, 2026, 6:31 AM Detection (updated detection logic) Plugin metadata Plugin Feed: 202602040631
Version 1.3 Jan 10, 2026, 7:58 PM Detection (updated detection logic) Plugin Feed: 202601101958
Version 1.2 Dec 19, 2025, 2:41 AM Detection (updated detection logic) Plugin metadata Plugin Feed: 202512190241
Version 1.1 Dec 18, 2025, 1:27 AM New Plugin Feed: 202512180127