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

  - ksmbd：修正 SMB2_CLOSE 上延遲file_lock的釋放後使用，然後SMB2_CANCEL提交 f580d27e8928 （ksmbd：修正雙SMB2_CANCEL上延遲file_lock的釋放後使用），使 smb2_cancel（） 跳過狀態為 KSMBD_WORK_CANCELLED 的工作，因此無法再次觸發其cancel_fn。但KSMBD_WORK有三種狀態 （ACTIVE、CANCELLED、CLOSED），且 CLOSED 也會達到相同的釋放生產者路徑：
    鎖定控點 -> set_close_state_blocked_works（） 上的SMB2_CLOSE會將延遲工作的狀態設定為 KSMBD_WORK_CLOSED，並喚醒 smb2_lock（） 工作角色。工作者採用非 ACTIVE 提前退出，locks_free_lock（）file_lock，並且由於狀態不KSMBD_WORK_CANCELLED，因此採用帶有 goto out2 的STATUS_RANGE_NOT_LOCKED分支 -- 與取消的分支一樣，跳過 release_async_work（）。工作保持在 conn->async_requests上，即時 cancel_fn = smb2_remove_blocked_lock指向釋放的file_lock。然後，同一 AsyncId 的後續SMB2_CANCEL會傳遞僅KSMBD_WORK_CANCELLED保護（其狀態為 KSMBD_WORK_CLOSED），因此 smb2_cancel（） 會在釋放的file_lock上再次觸發 cancel_fn - 透過 SMB2_CLOSE 而不是第一個SMB2_CANCEL修復了相同的釋放後使用： 錯誤：KASAN：__locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel < 中的 slab-use-after-free - 第二次SMB2_CANCEL觸發cancel_fn handle_ksmbd_work 分配方式 ...： locks_alloc_lock <- smb2_lock 釋放方式 ...：
    locks_free_lock <- smb2_lock （非作用中提前退出） ...大小為 192 的快取file_lock_cache由經過驗證的 SMB 用戶端使用 KASAN 在主線 7.1-rc7（已包含 f580d27e8928）上重現;雙SMB2_CANCEL控制在該核心上是無訊息的，因此 splat 可歸因於 CLOSE 觸發程序。
    只有 ACTIVE 延遲工作才能觸發其cancel_fn：兩個終端狀態 （CANCELLED 和 CLOSED） 都會到達釋放file_lock並跳過 release_async_work（） 的 smb2_lock（） 提前退出。保護KSMBD_WORK_ACTIVE以便跳過任何非作用中工作。（CVE-2026-64437）

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

偵測

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

high Nessus Plugin ID 329950

版本 1.13