PT-2026-61429 · Linux · Linux

CVE-2026-64112

·

Publicado

2026-07-19

·

Atualizado

2026-07-19

CVSS v3.1

7.8

Alta

VetorAV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
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 ", 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().

Correção

Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾

Identificadores relacionados

CVE-2026-64112

Produtos afetados

Linux