Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ksmbd：修复 SMB2_CLOSE 然后SMB2_CANCEL提交时延迟file_lock的释放后使用 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（）s 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 <- 2nd SMB2_CANCEL 中的 slab-use-after-freecancel_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）都到达 smb2_lock（） 提早退出，从而释放file_lock并跳过 release_async_work（）。保护KSMBD_WORK_ACTIVE以便跳过任何非活动工作。（CVE-2026-64437）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2026-64437

high Nessus 插件 ID 329950

版本 1.13