CVE-2026-64112 json
rbd: eliminate a race in lock_dwork draining on unmap
published 2026-07-19 3 mo ago modified 2026-10-19 20 d ago also EUVD-2026-45797
- cvss
- 7.8
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.1%
- EPSS 0.1% chance of exploitation in 30 days, percentile 0%
- public exploits
- 0
- none known
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 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().
Patch / fix
- Linux Linux 6.12.92, 6.18.34, 7.0.11, 7.1
- linux Debian 13 6.12.94-1
- linux Debian 14 7.0.12-1
debian advisories DEBIAN-CVE-2026-64112
- linux Ubuntu 26.04 LTS 7.0.0-28.28
- linux-aws Ubuntu 26.04 LTS 7.0.0-1009.9
- linux-gcp Ubuntu 26.04 LTS 7.0.0-1008.8
- linux-gke Ubuntu 26.04 LTS 7.0.0-1003.4
- linux-ibm Ubuntu 26.04 LTS 7.0.0-1010.10
- linux-azure Ubuntu 26.04 LTS 7.0.0-1010.10
- linux-raspi Ubuntu 26.04 LTS 7.0.0-1015.15
- linux-riscv Ubuntu 26.04 LTS 7.0.0-28.28.1
ubuntu advisories UBUNTU-CVE-2026-64112
Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
- kernel-64kb SLE Module for Basesystem 15 SP7 6.4.0-150700.53.81.1
- kernel-syms SLE Module for Development Tools 15 SP7 6.4.0-150700.53.81.1
- kernel-azure SLE Module for Public Cloud 15 SP7 6.4.0-150700.53.81.1
- kernel-source SLE Module for Development Tools 15 SP7, SLE Module for Basesystem 15 SP7 6.4.0-150700.53.81.1
- kernel-default SLE Workstation Extension 15 SP7, SLE Module for Legacy 15 SP7, SLE Module for Basesystem 15 SP7 +2 more 6.4.0-150700.53.81.1
- kernel-zfcpdump SLE Module for Basesystem 15 SP7 6.4.0-150700.53.81.1
- kernel-obs-build SLE Module for Development Tools 15 SP7 6.4.0-150700.53.81.1
- kernel-default-base SLE Module for Basesystem 15 SP7 6.4.0-150700.53.81.1.150700.17.45.1
suse advisories SUSE-SU-2026:4254-1SUSE-SU-2026:23887-1SUSE-SU-2026:23902-1SUSE-SU-2026:23897-1SUSE-SU-2026:23881-1SUSE-SU-2026:4120-1
- kernel-rt openSUSE Leap 16.0 6.12.0-160000.38.1
- dtb-aarch64 openSUSE Leap 16.0 6.12.0-160000.38.1
- kernel-64kb openSUSE Leap 16.0 6.12.0-160000.38.1
- kernel-syms openSUSE Leap 16.0 6.12.0-160000.38.1
- kernel-azure openSUSE Leap 16.0 6.12.0-160000.38.1
- kernel-obs-qa openSUSE Leap 16.0 6.12.0-160000.38.1
- kernel-source openSUSE Leap 16.0 6.12.0-160000.38.1
- kernel-default openSUSE Leap 16.0 6.12.0-160000.38.1
opensuse advisories openSUSE-SU-2026:21910-1
Vendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2026-64112 updated cvss 4.7
kernel: rbd: eliminate a race in lock_dwork draining on unmap
-
Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernelaffected: workaround, no fix available “Fix deferred”
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 morenot affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
CISA SSVC
- Exploitation
- none
- Automatable
- no
- Technical impact
- total
- Assessed
- 23 d ago
Exploit prediction
0.10% chance of exploitation in the next 30 days, higher than 0% of all scored CVEs (FIRST EPSS, 2026-11-08).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 3.1 | 7.8 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
Affected products
- Linux Linux
Classification
- Weakness
- Technology feeds
References
Sources
- CVE List CVE-2026-64112
- NVD CVE-2026-64112
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.