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

  - rbd：消除取消映射時 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）; }lock_dwork在 delayed_work_pending（） 傳回 true 後立即被取消，並且 mod_delayed_work（） 無論如何都會將其重新排隊，這並非不切實際。這是一場經典的 TOCTOU 比賽。在取消映射圖像時，有一個隱含的假設，即在 rbd_dev_image_unlock（） 的返回點之後沒有自我啟動的排他鎖定活動，如果碰巧被持有，則解鎖鎖定。此解鎖被認為是最終的，並且lock_dwork（以及所有其他獨佔鎖定任務，實際上）預計不會再次排入佇列。
    但是，lock_dwork僅在 cancel_tasks_sync（） 中被取消（即在取消映射序列的後面），並且最重要的是取消實際上可以被 maybe_kick_acquire（） 無效。這可能會導致 rbd_acquire_lock（） 在 rbd_dev_device_release（） 和 rbd_dev_image_release（） 執行後執行，並釋放和/或重設一堆東西。其中一種可能的故障模式是違反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 Plugin ID 327912

版本 1.1