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

  - eventpoll: 在仍持有 ep mutex 時不要遞減 ep 參照計數。Jann Horn 指出，epoll 會先遞減 ep 參照計數，然後再執行 mutex_unlock(&ep->mtx);。這樣做非常不妥，可能會導致釋放後使用錯誤。不過對於最後一個參照而言，這種模式是可行的，因為相關程式碼會延遲，直到解鎖 mutex 後才實際呼叫 ep_free(ep)。然而對於更微妙的倒數第二種情況而言，這樣做是錯誤的，在此情境下其他人也可能釋放他們的參照並在我們仍使用 mutex 時釋放 ep。請注意，即使其他使用者也在使用同一個 ep mutex，這依然成立: mutex 與 spinlock 不同，不能用來表示對物件的擁有權，即使它們保證互斥。mutex 解除鎖定作業不是原子性的，當一個使用者仍在存取 mutex 作為解鎖的一部分時，另一個使用者可能進入並取得已釋放的 mutex，同時釋放資料結構，而此時第一個使用者仍在清理。請參閱我們在 Documentation/locking/mutex-design.rst 的 mutex 說明文件，特別是關於語意的第 [1] 節:
    即使 mutex_unlock() 已經在內部釋放鎖定，它仍可能存取 mutex 結構，因此另一個上下文取得 mutex 並假設 mutex_unlock() 的上下文不再使用該結構是不安全的。因此，如果我們在 mutex 解鎖之前釋放 ep 參照，但我們不是最後一個參照者，接著我們解鎖 mutex，另一個使用者進來釋放他們的參照，並釋放此時已無使用者的 ep——而 mutex_unlock() 仍在存取它。透過將 ep 的參照計數減少操作移到 mutex 外部即可修復: 參照計數本身是原子性的，並不需要 mutex 保護 (這正是參照計數的意義所在: 與 mutex 不同，它本質上是物件生命週期的管理工具)。
    (CVE-2025-38349)

請注意，Nessus 依賴供應商報告的套件存在。

偵測

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

high Nessus Plugin ID 244743

版本 1.32