CVE-2026-64112

/// Technical description

In the Linux kernel, the following vulnerability has been resolved:

rbd: eliminate a race in lock_dwork draining on unmap

Given how rbd_lock_add_request() and rbd_img_exclusive_lock() are

written, lock_dwork may be (re)queued more than it's actually needed:

for example in case a new I/O request comes in while we are in the

middle of rbd_acquire_lock() on behalf of another I/O request. This is

expected and with rbd_release_lock() preemptively canceling lock_dwork

is benign under normal operation.

A more problematic example is 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);

}

It's not unrealistic for lock_dwork to get canceled right after

delayed_work_pending() returns true and for mod_delayed_work() to

requeue it right there anyway. This is a classic TOCTOU race.

When it comes to unmap

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References