CVE-2026-64112: Linux Kernel Race Condition Vulnerability

CVE-2026-64112 Overview

CVE-2026-64112 is a race condition in the Linux kernel's RADOS Block Device (rbd) driver. The flaw resides in the exclusive lock task draining logic during image unmap operations. A Time-of-Check Time-of-Use (TOCTOU) race between maybe_kick_acquire() and cancel_tasks_sync() allows lock_dwork to be requeued after rbd_dev_image_unlock() completes. This can cause rbd_acquire_lock() to execute after rbd_dev_device_release() and rbd_dev_image_release() have freed or reset device state, triggering assertion failures such as rbd_assert(rbd_image_format_valid(rbd_dev->image_format)) in rbd_dev_header_info().

Critical Impact
A local authenticated user with access to Ceph rbd operations can trigger kernel assertion failures or use-after-reset conditions, leading to denial of service or potential memory corruption in the kernel.

Affected Products

Linux kernel rbd (RADOS Block Device) driver
Systems using Ceph block devices via the kernel rbd module
Distributions shipping affected kernel versions prior to the referenced stable commits

Discovery Timeline

2026-07-19 - CVE-2026-64112 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-64112

Vulnerability Analysis

The vulnerability affects the exclusive lock lifecycle in the kernel rbd driver. The driver uses a delayed work item, lock_dwork, to acquire the Ceph exclusive lock asynchronously in response to incoming I/O requests. Under normal operation, the driver may queue lock_dwork more times than strictly required, which is benign because rbd_release_lock() preemptively cancels it.

The problem emerges during image unmap. The unmap path calls rbd_dev_image_unlock() to release the lock, then later calls cancel_tasks_sync() to drain outstanding work. Between these two calls, maybe_kick_acquire() can requeue lock_dwork because its check-then-act pattern is not atomic with the surrounding state transitions.

Root Cause

The root cause is a classic TOCTOU race in maybe_kick_acquire():

if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {
        mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0);
}

Between the delayed_work_pending() check and the mod_delayed_work() call, another context can cancel lock_dwork. mod_delayed_work() then requeues it regardless. Combined with the fact that lock_dwork cancellation happens later than rbd_dev_image_unlock() in the unmap sequence, this violates the implicit contract that no self-initiated exclusive lock activity occurs after unlock returns.

Attack Vector

Exploitation requires local access with the ability to map and unmap rbd images or issue I/O against them concurrently. An attacker who can race I/O submission against an unmap operation can trigger rbd_acquire_lock() execution against a partially-released device. This may cause rbd_dev_refresh() to observe freed or reset fields, invoking rbd_assert() on invalid state and producing a kernel panic. Depending on kernel configuration and the exact interleaving, the freed state access could also lead to memory corruption.

Detection Methods for CVE-2026-64112

Indicators of Compromise

Kernel panic or BUG/WARNING traces referencing rbd_dev_header_info, rbd_dev_refresh, or rbd_post_acquire_action
Assertion failures citing rbd_image_format_valid in kernel logs (dmesg, /var/log/kern.log)
Unexpected rbd device state resets or map/unmap operations timing out under concurrent I/O load

Detection Strategies

Monitor kernel ring buffer for rbd-related assertion failures and use-after-free warnings via KASAN builds
Correlate rbd unmap operations with concurrent I/O submissions in host telemetry
Track kernel version inventory against the fixed stable commits referenced in the Kernel Git history

Monitoring Recommendations

Aggregate dmesg output from Ceph client nodes into a centralized log platform and alert on rbd_assert strings
Instrument node health checks to detect kernel panics on hosts that mount Ceph block devices
Audit which users and containers can invoke rbd map/rbd unmap operations

How to Mitigate CVE-2026-64112

Immediate Actions Required

Inventory all hosts running the kernel rbd driver against Ceph clusters and identify kernels lacking the upstream fix
Apply the stable kernel updates that include the corrected exclusive lock task draining logic
Restrict access to rbd map/unmap operations to trusted administrative users only

Patch Information

The fix redesigns exclusive lock task draining to provide correct semantics around rbd_dev_image_unlock(). Fixes are available in the following upstream commits: 3427d7ae3833, 9400efc76b42, 9dcd4f5c99b4, and 9fc75b71fdd3. Apply distribution kernel updates that include these commits.

Workarounds

Avoid concurrent I/O against rbd images during unmap operations; quiesce workloads before invoking rbd unmap
Where feasible, use the user-space librbd client via rbd-nbd or QEMU instead of the in-kernel rbd driver until patches are applied
Limit which non-root users and containers can perform rbd device operations through capability restrictions

bash

# Verify running kernel and check for the fix commits
uname -r
modinfo rbd | grep -E 'version|srcversion'

# Quiesce workloads before unmap to avoid triggering the race
sync && rbd unmap /dev/rbd0