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

  - nfsd：RCU 保護cl_cb_session，用於修正工作階段拆卸時的釋放後使用 DESTROY_SESSION後，每個工作階段的拆卸路徑可以釋放工作階段，而 rpciod 仍保留取消參照 clp->cl_cb_session 的進行中回呼rpc_task。nfsd4_probe_callback_sync（） 會刷新cl_callback_wq，但一旦 nfsd4_run_cb_work（） 調用 rpc_call_async（），rpc_task 就會存在於 rpciod 上;排清工作佇列不會等待它。rpc_shutdown_client（） 確實會耗盡 rpciod 任務，但會使用 1 秒wait_event_timeout卡在 rpc_delay（） 中的任務 （例如 2 秒的NFS4ERR_DELAY重試） 可以比耗盡任務更長的時間。銷毀路徑 rpciod ------------ ------ unhash_session（ses） nfsd4_probe_callback_sync（clp） flush_workqueue（cl_callback_wq） /* 傳回;rpc_task仍然活躍 */ nfsd4_put_session_locked（ses） free_session（ses） -> kfree（ses） nfsd4_cb_sequence_done（） 讀取 cb_clp->cl_cb_session /* 釋放的 slab */ nfsd4_process_cb_update（） 中存在第二個視窗。當 __nfsd4_find_backchannel（） 傳回 NULL 時，因為 unhash_session（） 已經從 cl_sessions 中移除已銷毀的工作階段，setup_callback_client（） 會接受 v4.1 的早期傳回，因此 clp->cl_cb_session = ses 永遠不會觸發，且欄位會保留指向即將釋放的工作階段的指標。透過將 cl_cb_session 轉換為受 RCU 保護的指標來修正這兩個問題： - 將 setup_callback_client（） 中的 cl_cb_session = ses 指派移至 rpc_create（） 成功之後，因此只有在存在有效的反向通道時才會發佈。清除 nfsd4_process_cb_update（） 中錯誤傳回的cl_cb_session。兩個存放區都使用 rcu_assign_pointer（）。- 用__rcu註解cl_cb_session。所有 rpciod 端讀取器都使用 rcu_read_lock（）/rcu_dereference（） 並檢查 NULL，從而找到適當的錯誤或重新排隊路徑：encode_cb_sequence4args（）、decode_cb_sequence4resok（）、nfsd41_cb_get_slot（）、nfsd41_cb_release_slot（）、nfsd4_cb_prepare（） 和 nfsd4_cb_sequence_done（）。- 將 __free_session（） 從 kfree（） 切換為 kfree_rcu（），以便在 RCU 寬限期過後才會回收工作階段 slab，從而保證 rcu_read_lock（） 內的 rpciod 讀取器永遠不會取消參照釋放的記憶體。- 將階段作業指標傳遞至nfsd_cb_seq_status並nfsd_cb_free_slot追蹤點，而不是讓它們重新讀取cl_cb_session。- 當工作階段為 NULL 時，nfsd4_cb_prepare（） 呼叫 rpc_exit（），透過完成/釋放路徑路由以將回呼重新排入佇列。（CVE-2026-89708）

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

偵測

Linux Distros 未修補弱點：CVE-2026-89708

critical Nessus Plugin ID 345421

版本 1.4