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

  - rbd：消除 unmap 上 lock_dwork 耗尽中的争用 鉴于 rbd_lock_add_request（） 和 rbd_img_exclusive_lock（） 的写入方式，lock_dwork 可能（重新）排队的时间超过实际需要的次数：例如，当我们代表另一个 I/O 请求在 rbd_acquire_lock（） 中间时，有一个新的 I/O 请求传入。这是正常情况，且通过 rbd_release_lock（） 抢先取消lock_dwork在正常操作中是安全的。一个更成问题的例子是 maybe_kick_acquire（）： if （have_requests || delayed_work_pending（&rbd_dev->lock_dwork）） { dout（%s rbd_dev %p kicking lock_dwork\n， __func__， rbd_dev）; mod_delayed_work（rbd_dev->task_wq， &rbd_dev->lock_dwork， 0）; }在 delayed_work_pending（） 返回 true 后立即取消 lock_dwork 并让 mod_delayed_work（） 重新排队并非不现实。这是一场经典的 TOCTOU 比赛。在取消映射图像时，隐式假设超过来自 rbd_dev_image_unlock（） 的返回点后没有任何自我启动的排他锁活动，如果碰巧持有锁，则解锁该锁。此解锁被认为是最终的，并且lock_dwork（以及所有其他独占锁定任务，实际上）预计不会再次排队。
    但是，lock_dwork仅在 cancel_tasks_sync（） 中（即取消映射序列的后面）中取消，最重要的是，取消实际上可能被 maybe_kick_acquire（） 无效化。这可能导致 rbd_dev_device_release（） 和 rbd_dev_image_release（） 运行后执行 rbd_acquire_lock（），并释放和/或重置一堆东西。其中一种可能的失败模式是违反rbd_assert（rbd_image_format_valid（rbd_dev->image_format））;在 rbd_dev_header_info（） 中，通过从 rbd_post_acquire_action（） 的 rbd_dev_refresh（） 调用。重做独占锁定任务耗尽，以提供更合理的语义，并尝试满足关于 rbd_dev_image_unlock（） 的假设。（CVE-2026-64112）

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

检测

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

high Nessus 插件 ID 327912

版本 1.7