---
id: CVE-2026-64112
title: 'rbd: eliminate a race in lock_dwork draining on unmap'
summary: |-
  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…
severity: high
cvss: 7.8
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
cvssSource: cna
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= fd22aef8b47cfc068448df65c1183698b0abd815 <
    3427d7ae38337066ce88b68302e285d344ab756b
  - >-
    Linux >= fd22aef8b47cfc068448df65c1183698b0abd815 <
    9dcd4f5c99b491c37be90b0bd9988db48225fb75
  - >-
    Linux >= fd22aef8b47cfc068448df65c1183698b0abd815 <
    9400efc76b42c751211974a25c91d2c19c65b01b
  - >-
    Linux >= fd22aef8b47cfc068448df65c1183698b0abd815 <
    9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90
  - Linux 4.12
ssvc:
  exploitation: none
  automatable: 'no'
  technicalImpact: total
  timestamp: '2026-10-16T15:36:26.577928Z'
published: '2026-07-19'
updated: '2026-10-16'
sourceUpdated: '2026-10-16T15:42:22.660Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-64112'
references:
  - url: 'https://git.kernel.org/stable/c/3427d7ae38337066ce88b68302e285d344ab756b'
  - url: 'https://git.kernel.org/stable/c/9dcd4f5c99b491c37be90b0bd9988db48225fb75'
  - url: 'https://git.kernel.org/stable/c/9400efc76b42c751211974a25c91d2c19c65b01b'
  - url: 'https://git.kernel.org/stable/c/9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90'
tags:
  - cve.org
epss: 0.00099
epssPercentile: 0.00785
ingestedAt: '2026-10-16T17:24:46.805Z'
---

## Overview

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().

## Affected

- `Linux >= fd22aef8b47cfc068448df65c1183698b0abd815 < 3427d7ae38337066ce88b68302e285d344ab756b`
- `Linux >= fd22aef8b47cfc068448df65c1183698b0abd815 < 9dcd4f5c99b491c37be90b0bd9988db48225fb75`
- `Linux >= fd22aef8b47cfc068448df65c1183698b0abd815 < 9400efc76b42c751211974a25c91d2c19c65b01b`
- `Linux >= fd22aef8b47cfc068448df65c1183698b0abd815 < 9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90`
- `Linux 4.12`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.