CVE-2026-64112: Linux kernel · Race Condition
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 7.8 High · fixed in 9400efc76b42c751211974a25c91d2c19c65b01b : patch Linux kernel soon.
Data as of 26 Oct 2026, 14:05 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 0% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers cannot reliably automate steps 1–4 of the kill chain
- Technical impact
- Total control over the software or total information disclosure
CISA SSVC assessment, 2026-10-16.
- Patch
- Available – fixed in 9400efc76b42c751211974a25c91d2c19c65b01b, 3427d7ae38337066ce88b68302e285d344ab756b, 9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90 +1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 19 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade Linux kernel to 9400efc76b42c751211974a25c91d2c19c65b01b, 3427d7ae38337066ce88b68302e285d344ab756b, 9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90 or 9dcd4f5c99b491c37be90b0bd9988db48225fb75.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
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().
References
- git.kernel.org/stable/c/3427d7ae38337066ce88b68302e285d344ab756b (opens in a new tab)
- git.kernel.org/stable/c/9dcd4f5c99b491c37be90b0bd9988db48225fb75 (opens in a new tab)
- git.kernel.org/stable/c/9400efc76b42c751211974a25c91d2c19c65b01b (opens in a new tab)
- git.kernel.org/stable/c/9fc75b71fdd38465c76c6f6a884cdd4ae3c72d90 (opens in a new tab)