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

  - af_unix如果有 MSG_PEEK 介入則放棄 GC。Igor Ushakov 報告GC 已清除活動中通訊端的接收佇列這是因為與具有良好重現的 MSG_PEEK 發生爭用所導致。這與先前由認可 cbcf01128d0a 修正的問題完全相同 (af_unix修正記憶體回收與 MSG_PEEK 的問題)。在以目前的演算法取代 GC 之後被引用的認可移除了 unix_peek_fds() 中的鎖定 Dance並再次出現相同的問題。問題在於 MSG_PEEK 在未與 GC 互動的情況下增加檔案 refcount。請考慮包含 sk-A 和 sk-B 的 SCC其中 sk-A 是 close()d但可以透過 sk-B recv()ed。如果在 GC 檢查 sk-A 和 sk-B 的 unix_vertex_dead() 時sk-A 使用 sk-B 的 MSG_PEEK recv() recv()且 sk-B close()d就會發生不良情況。GC 執行緒 使用者執行緒 --------- ----------- unix_vertex_dead(sk-A) -> true <------。 \ `------ recv(sk-B, MSG_PEEK) 無效 !! -> sk-A 的檔案參照計數 1 -> 2 close(sk-B) -> sk-B 的檔案參照計數 2 -> 1 unix_vertex_dead(sk-B) -> true sk-A 的檔案參照計數最初由sk-B recvq 中的 inflight fd。GC 認為 sk-A 已失效因為檔案 refcount 與其傳送 fds 的數目相同。不過sk-A 的檔案參照計數會遭到 MSG_PEEK 以無訊息的方式增加進而使先前的評估失效。此時sk-B 的檔案 refcount 為 2一項由 open fd 決定另外一項由 sk-A 中的 inflight fd 決定。隨後的 close() 會依前者釋出一個 refcount。最後GC 會錯誤地斷定 sk-A 和 sk-B 皆已失效。一個選項是還原 unix_peek_fds() 中的鎖定 Dance但由於有了新演算法我們可以更巧妙地解決此問題。重點是沒有後續的 close() 就不會發生此問題而且我們實際上不需要將 MSG_PEEK 與失效的 SCC 偵測同步。當問題發生時close() 和 GC 接觸相同的檔案參照計數。如果 GC 發現 refcount 因 close() 而遞減它就可以放棄對 SCC 進行記憶體回收。因此我們只需要在 MSG_PEEK 期間使用適當的記憶體障礙來發出爭用信號以使其對 GC 可見。讓我們使用 seqcount_t 在發生 MSG_PEEK 時通知 GC並讓它延遲 SCC 至下次執行。如此一來就不需要在 MSG_PEEK 端進行任何鎖定而且我們可以避免對每個 MSG_PEEK 施加不必要的損失。請注意如果偵測到 MSG_PEEK我們可以在 unix_scc_dead() 內重試但我們不會這麼做是為了避免因濫用的 MSG_PEEK 呼叫而懸置工作噴濺。 (CVE-2026-23394)

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

偵測

Linux Distros 未修補的弱點：CVE-2026-23394

medium Nessus Plugin ID 303674

版本 1.10