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

  - 還原 smb用戶端修正 rmmod 後的 TCP 計時器鎖死。這會還原認可 e9f2517a3e18a54a3943c098d2226b245d488801。認可 e9f2517a3e18 (smb用戶端修正 rmmod 後的 TCP 計時器鎖死) 旨在修正 LOCKDEP 中的 null-ptr-deref這稱為 CVE-2024-54680但實際上並未任何修正此問題可能會在此基礎上重現。 [0] 此外它還還原了提交 ef7134c7fc48 的變更 (smb用戶端修正網路命名空間的釋放後使用)並因恢復核心 TCP 通訊端而引入一個實際問題。當 CIFS 連線發生重新連線時通訊端狀態會轉換為 FIN_WAIT_1。然後tcp_close() 中的 inet_csk_clear_xmit_timers_sync() 會停止通訊端的所有計時器。如果遺失傳入的 FIN 封包通訊端將永遠停留在 FIN_WAIT_1而此類通訊端可洩漏至 net.ipv4.tcp_max_orphans。通常對等端可以重新傳輸 FIN但如果對等端中止連線問題就會發生。我透過指出確切的報告 [1] 私下警告過這點但假的修正最終還是會合併。因此在這種情況下我們不應停止計時器最終終止我們的連線這表示我們不得針對 sk->sk_net_refcnt 為 0 的 TCP 使用核心通訊端。核心通訊端沒有其 netns 的參照可在不清除其中所有資源的情況下終止 netns。例如通道裝置在內部使用 UDP 通訊端但我們可以在不移除此類裝置的情況下損毀 netns並使其在結束時完成。
    否則netns 會在最後一個應用程式停止回應時遭到洩漏。但是對於 TCP 通訊端這是有問題的因為 TCP 有計時器可以正常關閉連線即使在通訊端執行 close()d 之後也是如此。通訊端及其 netns 的存留期與基礎連線的存留期不同。如果通訊端使用者不維持 netns 存留期則可在通訊端執行 close()d 並釋放其 netns 後觸發計時器進而導致釋放後使用。實際上我們已經看到過許多類似的問題並且將此類通訊端轉換為具有 netns 的參照。這就是我轉換 CIFS 用戶端通訊端使其具有 netns (sk->sk_net_refcnt == 1) 參照的原因這在某種程度上被提及為超出 CIFS 範圍且 e9f2517a3e18 中有技術錯誤但**在範圍內 且正確修正**。關於 LOCKDEP 問題我們可以在 sock_lock_init_class_and_name() 中切換 LOCKDDEP 金鑰時透過增加模組 refcount 來防止模組卸載。 [2] 我們暫時還原假的修正。請注意現在我們可針對通訊端轉換使用 sk_net_refcnt_upgrade()但稍後我會分開執行以使反向移植更容易。
    (CVE-2025-22077)

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

偵測

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

medium Nessus Plugin ID 249058

版本 1.19