CVE-2026-64112

rbd: eliminate a race in lock_dwork draining on unmap

Published Jul 19, 2026 CVSS 3.1 · 7.8 High EPSS < 1% KEV · Not listed
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 unmapping the image, there is an implicit assumption
of no self-initiated exclusive lock activity past the point of return
from rbd_dev_image_unlock() which unlocks the lock if it happens to be
held. This unlock is assumed to be final and lock_dwork (as well as
all other exclusive lock tasks, really) isn't expected to get queued
again. However, lock_dwork is canceled only in cancel_tasks_sync()
(i.e. later in the unmap sequence) and on top of that the cancellation
can get in effect nullified by maybe_kick_acquire(). This may result
in rbd_acquire_lock() executing after rbd_dev_device_release() and
rbd_dev_image_release() run and free and/or reset a bunch of things.
One of the possible failure modes then is a violated

rbd_assert(rbd_image_format_valid(rbd_dev->image_format));

in rbd_dev_header_info() which is called via rbd_dev_refresh() from
rbd_post_acquire_action().

Redo exclusive lock task draining to provide saner semantics and try
to meet the assumptions around rbd_dev_image_unlock().

Remediation

No solution or workaround provided in the CVE record

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Ubuntu USN Ubuntu USN USN-8593-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8603-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8618-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8663-1 Linux kernel (NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-8664-1 Linux kernel (NVIDIA BaseOS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8728-1 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-8781-1 Linux kernel (NVIDIA Tegra) vulnerabilities
Ubuntu USN Ubuntu USN USN-8728-2 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8728-3 Linux kernel (Oracle) vulnerabilities
History
Type Values Removed Values Added
Weaknesses CWE-362
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}

Type Values Removed Values Added
CPEs cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:*
Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Type Values Removed Values Added
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 unmapping the image, there is an implicit assumption of no self-initiated exclusive lock activity past the point of return from rbd_dev_image_unlock() which unlocks the lock if it happens to be held. This unlock is assumed to be final and lock_dwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again. However, lock_dwork is canceled only in cancel_tasks_sync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybe_kick_acquire(). This may result in rbd_acquire_lock() executing after rbd_dev_device_release() and rbd_dev_image_release() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated rbd_assert(rbd_image_format_valid(rbd_dev->image_format)); in rbd_dev_header_info() which is called via rbd_dev_refresh() from rbd_post_acquire_action(). Redo exclusive lock task draining to provide saner semantics and try to meet the assumptions around rbd_dev_image_unlock().
Title rbd: eliminate a race in lock_dwork draining on unmap
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References
Weaknesses

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Oct 19, 2026, 8:28 PM
Reserved
Jul 19, 2026, 7:54 AM
Status
Modified
Published
Jul 19, 2026, 4:17 PM
Modified
Oct 19, 2026, 9:17 PM
Severity
Moderate
Public date
Jul 19, 2026, 12:00 AM