CVE-2026-64112: rbd: eliminate a race in lock_dwork draining on unmap

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

rbd: eliminate a race in lockdwork draining on unmap

Given how rbdlockaddrequest() and rbdimgexclusivelock() are written, lockdwork 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 rbdacquirelock() on behalf of another I/O request. This is expected and with rbdreleaselock() preemptively canceling lockdwork is benign under normal operation.

A more problematic example is maybekickacquire():

if (haverequests || delayedworkpending(&rbddev->lockdwork)) { dout("%s rbddev %p kicking lockdwork\n", func, rbddev); moddelayedwork(rbddev->taskwq, &rbddev->lockdwork, 0); }

It's not unrealistic for lockdwork to get canceled right after delayedworkpending() returns true and for moddelayedwork() 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 rbddevimageunlock() which unlocks the lock if it happens to be held. This unlock is assumed to be final and lockdwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again. However, lockdwork is canceled only in canceltaskssync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybekickacquire(). This may result in rbdacquirelock() executing after rbddevdevicerelease() and rbddevimagerelease() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated

rbdassert(rbdimageformatvalid(rbddev->imageformat));

in rbddevheaderinfo() which is called via rbddevrefresh() from rbdpostacquireaction().

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