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

  - af_unix初始化 unix_add_edge() 中的 scc_index。Quang Le 報告AF_UNIX GC 可以記憶體回收活動中執行中通訊端的接收佇列 (以 nice repro)。repro 包含三個階段。 1) 1-a. 建立具有多個通訊端 1-b 的單一周期性參照。 close() 所有通訊端 1-c。觸發 GC 2) 2-a. 將 sk-A 傳遞至原始 sk-B 2-b。將 sk-X 傳遞至 sk-X 2-c。觸發 GC 3) 3-a. accept() 啟動 sk-B 3-b。將 sk-B 傳遞至 sk-C 3-c。 close() 執行中 sk-A 3-d。觸發 GC 自 2-c 起sk-A 和 sk-X 會連結至 unix_unvisited_vertices且 unix_walk_scc() 會將它們分組為兩個不同的 SCC
    unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3 一旦 GC 完成unix_graph_grouped 就會設為 true。此外由於 sk-X 的周期性自我參照 unix_graph_maybe_cycle 設為 true這會使 close() 觸發 GC。在 3-bunix_add_edge() 會配置 unix_sk(sk-B)->vertex 並將其連結至 unix_unvisited_vertices。 3-a 會呼叫 unix_update_graph()。及 3-b.但 unix_graph_grouped 與 unix_graph_maybe_cycle 皆不會變更因為 sk-B 的接聽程式和 sk-C 都未進行中。 3-c 將 sk-A 的檔案 refcnt 遞減至 1。由於 unix_graph_grouped 在 3-d 為 true因此最終會呼叫 unix_walk_scc_fast() 並重複執行 3 個通訊端 sk-A、sk-B 和 sk-Xsk-A -> sk -B (-> sk-C) sk-X -> sk-X 這是完全沒有問題的。所有這些 SCC 都尚未執行 close()d且應編入不同的 SCC。但是unix_vertex_dead() 錯誤判斷為 sk-A 和 sk-B 位於同一個 SCC 中而 sk-A 已失效。 unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index <-- 錯誤&& sk-A 的檔案 refcnt == unix_sk(sk-A)->vertex->out_degree ^-- sk-B 的 1 個 in-flight 計數 -> sk-A 已失效 !? 問題在於 unix_add_edge() 未初始化 scc_index。階段 1) 用於堆積噴射使新配置的頂點具有 unix_walk_scc() 在 1-c 設定的 vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START)。
    讓我們追踪來自先前 unix_walk_scc() 呼叫的最大 SCC 索引並將 max + 1 指派給新頂點的 scc_index。如此一來我們就可繼續避免使用 Tarjan 演算法同時防止誤判。
    (CVE-2025-40214)

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

偵測

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

high Nessus Plugin ID 277490

版本 1.4