CVE-2026-64112

What it actually does

This flaw is a race condition in the Linux kernel RADOS Block Device (rbd) driver’s exclusive-lock work handling during image unmap. Under certain timing, delayed exclusive-lock work can be requeued after the unmap path assumes lock activity has stopped. That can allow rbd_acquire_lock() and follow-on refresh logic to run after rbd device structures have been released or reset, potentially causing kernel assertion failures, use-after-free-like behavior, memory corruption, kernel crash, or local privilege escalation depending on kernel build, hardening, and runtime conditions.

Why it matters to the business

Systems using Ceph RBD through the Linux kernel rbd driver may be exposed to local denial of service and potentially full host compromise by a user or workload with sufficient privileges to interact with mapped RBD devices. The main operational risk is host instability or kernel panic affecting storage consumers, virtualization hosts, container platforms, or application nodes backed by RBD. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so urgency should be highest for multi-user systems, shared compute platforms, and environments where untrusted or semi-trusted workloads can trigger RBD map, unmap, or I/O activity.

How an attack unfolds

An attacker first needs local access and the ability to interact with Linux kernel RBD mappings, typically through privileges or delegated tooling that can perform RBD I/O and unmap operations. The attacker drives concurrent activity against an RBD image so that exclusive-lock acquisition work is pending or requeued while the image is being unmapped. By repeatedly racing I/O-triggered lock acquisition against unmap and device release paths, the delayed lock work may execute after internal rbd structures have been freed or reset. The most likely observable outcome is a kernel warning, assertion failure, oops, or panic involving rbd lock or refresh functions. In a worst case, the race could produce memory corruption that may be exploitable for local privilege escalation, consistent with the high confidentiality, integrity, and availability impact reflected in the CVSS vector.

How to fix it

Apply the vendor-provided Linux kernel update that includes the fix for the rbd exclusive-lock task draining race. Because no exact fixed versions were provided, use the distribution or kernel vendor advisory for CVE-2026-64112 and verify the running kernel includes the upstream fix titled "rbd: eliminate a race in lock_dwork draining on unmap" or an equivalent backport. Reboot into the patched kernel after installation. Where immediate patching is not possible, reduce exposure by limiting which users, services, containers, and automation can map or unmap RBD devices; avoid granting untrusted workloads access to /dev/rbd* devices or RBD administration tooling; disable or unload the rbd kernel module on systems that do not require it; and consider using architecture controls that isolate RBD-capable workloads from shared or sensitive hosts.

How to confirm the fix worked

Confirm the system is running a patched kernel from the relevant Linux distribution or kernel vendor, not merely that the package is installed. Check kernel package changelogs, vendor advisories, or source patches for the rbd fix related to lock_dwork draining on unmap. Validate exposure by checking whether the rbd module is loaded and whether RBD devices are mapped using commands such as lsmod, modinfo rbd, rbd showmapped, and inspection of /sys/bus/rbd or /dev/rbd*. On patched test systems, exercise normal RBD map, I/O, exclusive-lock, and unmap workflows and confirm there are no kernel warnings, oopses, assertion failures, or rbd workqueue errors in kernel logs. On unpatched systems, avoid attempting to reproduce the race in production because successful triggering may crash the host.

Typical attack path

1. Obtain local access to a Linux system using the kernel rbd driver.
2. Gain the ability to interact with mapped Ceph RBD images or invoke tooling that maps, unmapps, or performs I/O against RBD devices.
3. Generate I/O activity that causes exclusive-lock acquisition attempts for an RBD image.
4. Concurrently trigger unmap or teardown of the same RBD image while delayed lock work is pending or being requeued.
5. Repeat the timing window until lock work executes after device release or reset.
6. Cause a kernel assertion failure, oops, panic, or potentially memory corruption leading to elevated privileges.

How to detect it

Look for evidence of local users or workloads repeatedly mapping, unmapping, and generating I/O against RBD devices shortly before kernel instability. Useful sources include kernel logs from journalctl -k or /var/log/kern.log, system crash dumps, kdump/vmcore data, auditd process execution logs, shell history for administrative accounts, Ceph client logs, sudo logs, and orchestration logs that invoke rbd map or rbd unmap. Investigate kernel oops, panic, BUG, WARNING, or assertion messages containing rbd function names from the exclusive-lock and refresh paths. Correlate these events with process execution of rbd, ceph, modprobe, umount, or automation that manipulates /dev/rbd* devices. Because there are no known public exploit indicators in the provided data, detection should focus on behavioral signs of race triggering: abnormal frequency of RBD unmaps, host crashes during RBD teardown, and kernel stack traces involving lock_dwork, rbd_acquire_lock, rbd_post_acquire_action, rbd_dev_refresh, or rbd_dev_header_info.

• rbd_assert(rbd_image_format_valid(rbd_dev->image_format))
• rbd_image_format_valid
• rbd_dev_header_info
• rbd_dev_refresh
• rbd_post_acquire_action
• rbd_acquire_lock
• rbd_release_lock
• maybe_kick_acquire
• lock_dwork
• kicking lock_dwork
• rbd_dev_image_unlock
• rbd_dev_device_release
• rbd_dev_image_release
• kernel BUG
• kernel panic
• Oops:
• WARNING: CPU:
• Call Trace:
• /sys/bus/rbd
• /dev/rbd
• /dev/rbd0
• rbd map
• rbd unmap
• modprobe rbd

What your security team should do

• Prioritize patching Linux hosts that load the rbd kernel module, especially virtualization, container, storage, and shared compute nodes.
• Inventory systems with mapped RBD devices by searching for the rbd kernel module, /dev/rbd* devices, and Ceph RBD client tooling.
• Restrict local privileges required to map, unmap, or perform administrative operations on RBD images to trusted administrators and service accounts only.
• Review container and workload policies to ensure untrusted workloads cannot access host RBD devices, privileged containers, host device mounts, or Ceph administrative credentials.
• Monitor kernel logs for rbd-related oopses, assertion failures, workqueue traces, or crashes involving rbd_acquire_lock, rbd_dev_refresh, or rbd_dev_header_info.
• If a host shows suspicious rbd-related kernel crashes, preserve kernel logs, crash dumps, audit logs, and recent RBD operation history before rebooting or rebuilding.
• Where RBD is not required, disable the rbd module and remove unnecessary Ceph client packages or access credentials.