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

  - nfs修正直接寫入中的 UAF。在生產中我們持續出現下列警告
    ------------[ 此處截斷 ]------------ refcount_t: underflow釋放後使用。警告CPU17 PID1800359@lib/refcount.c:28 refcount_warn_sature+0x9c/0xe0 工作佇列nfsiod nfs_direct_write_schedule_work [nfs] RIP0010:refcount_warn_sature+0x9c/0xe0 PKRU55555554 呼叫追踪 <TASK> ? __warn+0x9f/0x130 ? refcount_warn_sature+0x9c/0xe0 ? report_bug+0xcc/0x150 ? handle_bug+0x3d/0x70 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_sature+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs] process_one_work+0x12f/0x4a0 worker_thread+0x14e/0x3b0 ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120 ? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30 這是因為我們連續完成兩次 nfs_direct_request。造成這種情況的原因是當我們有提交認可要求時會先處理並寄出然後在提交要求的完成路徑中 if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq);不過由於我們是提交非同步要求有時某個要求會在我們提交下一個要求之前完成因此我們最終會在 nfs_direct_request 上呼叫 complete 兩次。我們使用 nfs_generic_commit_list() 的其他唯一位置是在 __nfs_commit_inode 中其將此呼叫包裝在 nfs_commit_begin() 中nfs_commit_end();這是此完成處理樣式的常見模式在使用 get_dreq()/put_dreq() 呼叫的直接程式碼中我們處理事件的位置及完成路徑也會重複此模式。透過對認可要求使用相同模式來修正此問題。在以 200 節點 rocksdb 執行壓力之前此警告會每 10 分鐘左右彈出一次。使用我的修補程式後壓力測試已執行數小時而未彈出。 (CVE-2024-26958)

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

偵測

Linux Distros 未修補的弱點：CVE-2024-26958

high Nessus Plugin ID 227537

版本 1.10