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

  - nvmet-tcp：修正 ICReq 處理與佇列拆卸之間的爭用 nvmet_tcp_handle_icreq（） 在傳送初始化連線回應 （ICResp） 之後更新佇列>狀態，但它不會針對目標端佇列拆卸進行序列化。如果 NVMe/TCP 主機發送初始化連接請求 (ICReq) 並立即關閉連接，則目標端拆卸可能會在 io_work 清空已緩衝的 ICReq 之前在 softirq 上下文中開始。在這種情況下，nvmet_tcp_schedule_release_queue（） 將 queue->state 設定為 NVMET_TCP_Q_DISCONNECTING，並將佇列參照放在 state_lock 下。如果io_work稍後處理該 ICReq，nvmet_tcp_handle_icreq（） 仍然可以將狀態覆寫回 NVMET_TCP_Q_LIVE。
    這會破壞 nvmet_tcp_schedule_release_queue（） 中的 DISCONNECTING-state guard，並允許稍後的通訊端狀態變更重新進入拆卸，並在已釋放的佇列上發出第二個 kref_put（）。ICResp 傳送失敗路徑也有相同的問題。如果拆卸操作已將佇列移至 DISCONNECTING，則傳送錯誤仍可將狀態覆寫為 NVMET_TCP_Q_FAILED，從而再次開啟窗口，允許第二次拆卸操作丟棄佇列引用。透過序列化使用 state_lock 的傳送後狀態轉換來修正此問題，並在拆卸已開始時退出。使用 -ESHUTDOWN 作為該救援路徑的內部哨兵，而不是將其傳播為傳輸錯誤，例如 -ECONNRESET。在接受該哨兵之前，將 nvmet_tcp_socket_error（） 設定rcv_state保持為NVMET_TCP_RECV_ERR，因此接收端剖析會保持靜止狀態，直到現有的發行路徑完成為止。（CVE-2026-46135）

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

偵測

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

critical Nessus Plugin ID 317631

版本 1.3