Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - netpoll修正 spinlock 下記憶體配置中的鎖死。修正 refill_skbs() 中的 AA 鎖死其中記憶體配置在保留 skb_pool->lock 時可觸發遞回鎖定取得嘗試。當系統處於下列嚴重記憶體壓力之下時會發生鎖死情形1. refill_skbs() 取得 skb_pool->lock (spinlock) 2. 保留鎖定時呼叫 alloc_skb() 3. 記憶體配置器失敗並呼叫 slab_out_of_memory() 4. 此觸發 OOM 警告的 printk() 5. 主控台輸出路徑呼叫 netpoll_send_udp() 6. netpoll_send_udp() 嘗試取得相同的 skb_pool->lock 7. 鎖死：鎖定已由相同 CPU 保留 呼叫堆疊refill_skbs( ) spin_lock_irqsave(&skb_pool->lock) <- 已取得鎖定 __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) <- 鎖死嘗試 此錯誤已由提交暴露248f6571fd4c51 (netpoll最佳化關鍵路徑上的 skb 重新填入)其已從關鍵路徑 (延遲巢狀 printk 的位置) 移除 refill_skbs()導致可從 refill_skbs() 內部呼叫巢狀 printk。將 refill_skbs() 重構為從不全部保留 spinlock 時 ocate 記憶體。修正此問題的另一個可能的解決方案是保護 refill_skbs() 不受巢狀 printks 攻擊基本上是呼叫 refill_skbs() 中的 printk_deferred_{enter,exit}()然後任何巢狀 pr_warn() 都會延遲。我偏好此方法因為 _think_ 建議未來將 alloc_skb() 從 GFP_ATOMIC 移至 GFP_KERNEL因此必須在鎖定之外執行 alloc_skb()。檢查集區長度並將新配置的 skb 排入佇列時可能有一個 TOCTOU 問題但是這不是問題因為集區中有一個額外的 SKB 是無害的且最終會被使用。 (CVE-2025-68169)

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

偵測

Linux Distros 未修補的弱點：CVE-2025-68169

medium Nessus Plugin ID 279006

版本 1.1