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

  - netfs修正參照洩漏提交 20d72b00ca81 (netfs修正要求的工作項目使其不需要 ref) 修改了 netfs_alloc_request()以將參照計數器初始化為 2 而非 1。基本原理是 reket 的工作會在 之後釋放第二個參照完成 (透過 netfs_{read,write}_collection_worker())。如果一切順利，這在大多數情況下都可以使用。但是如果在提交 I/O 作業之前釋放要求就會洩漏這個額外的參照錯誤程式碼路徑只會遞減參照計數器一次而且因為永遠不會有完成項目因此永遠不會將工作項目排入佇列。這已造成我們今天的整個伺服器叢集中斷因為工作在 netfs_wait_for_outstanding_io() 中遭到封鎖導致 Ceph 鎖死 (另一個錯誤我稍後會在另一個修補程式中加以解決)。這是由 fscache_begin_write_operation() 中失敗的 netfs_pgpriv2_begin_copy_to_cache() 呼叫所造成。洩漏的 netfs_io_request 從未完成而使 `netfs_inode.io_count` 永遠保持正值。所有這些都是超級脆弱的程式碼。找出哪些程式碼路徑將導致最終完成哪些不會導致完成不難。- 部分函式如 netfs_create_write_req() 會配置要求但永遠不會提交任何 I/O。 - netfs_unbuffered_read_iter_locked() 呼叫 netfs_unbuffered_read()然後呼叫 netfs_put_request()不過netfs_unbuffered_read() 也可能在提交 I/O 要求前提早失敗因此必須在此處新增另一個 netfs_put_request() 呼叫。根據經驗傳回 `netfs_io_request` 的函式不會提交 I/O因此必須檢查其所有呼叫者。依我的喜好需要徹底檢修整個 netfs 程式碼以使參照計數更容易理解且不那麼脆弱和模糊。
    但是為了此時此地修正此錯誤並產生足以進行穩定反向移植的修補程式我嘗試了一種在早期失敗時快速釋放要求物件的最小方法。我決定不每次都新增第二個 netfs_put_request()因為這會造成程式碼重複進而進一步模糊化程式碼。相反我新增了 netfs_put_failed_request() 函式該函式會在參照計數正好是 2 (最初由 netfs_alloc_request() 設定且從未動過)且由 WARN_ON_ONCE() 驗證的 假設下同步釋放此類失敗的要求。然後它會取消初始化要求物件 (不經過 cleanup_work 間接取值) 並釋放配置 (使用 RCU 保護防止 netfs_requests_seq_start() 進行的並行存取)。所有提早失敗的程式碼路徑皆已變更為呼叫 netfs_put_failed_request()而非 netfs_put_request()。此外我已如上所述將 netfs_put_request() 呼叫新增至 netfs_unbuffered_read()因為 netfs_put_failed_request() 方法在該處無法運作。 (CVE-2025-40007)

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

偵測

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

high Nessus Plugin ID 271665

版本 1.1