CVE-2026-46079

What it actually does

This is a Linux kernel denial-of-service flaw in the RADOS Block Device (RBD) driver error-handling path. When an RBD device is published with device_add() but device_add_disk() later fails, the cleanup path can free disk-related state twice and then re-enter block multi-queue cleanup with invalid or NULL state. The observed crash occurs in __blk_mq_free_map_and_rqs(), called from blk_mq_free_tag_set(), producing a kernel NULL-pointer dereference/general protection fault. The practical impact is local kernel crash or instability when an RBD device add operation fails at the vulnerable point; the issue does not indicate confidentiality or integrity compromise.

Why it matters to the business

Systems using the Linux kernel RBD driver for Ceph-backed block devices may be vulnerable to local denial of service. A successful trigger can crash the host or destabilize storage operations, causing workload interruption, failed mounts, VM or container disruption, and possible service downtime for applications depending on RBD-backed storage. The EPSS score is currently very low and it is not listed in CISA KEV, so broad exploitation is not indicated, but the operational impact is high for hosts where Ceph RBD is actively used.

How an attack unfolds

An attacker needs local access with sufficient privileges or delegated capability to initiate RBD device mapping through the kernel RBD interface, such as writing an RBD mapping request to the RBD sysfs add path. The attacker then causes or waits for device_add_disk() to fail after the device has already been registered by device_add(). In the vulnerable kernel, the failure path calls rbd_free_disk() directly and then later reaches the device release path, which attempts disk cleanup again. This inconsistent teardown sequence corrupts cleanup state and can drive the block layer into a NULL-pointer dereference in __blk_mq_free_map_and_rqs(). In a production environment, inducing the precise allocation failure may require memory pressure, resource exhaustion, fault-injection features, or unusual failure conditions during RBD mapping; the end result is a local availability attack rather than remote compromise.

How to fix it

Apply a vendor-supported kernel update that includes the RBD cleanup-ordering fix for the device_add_disk() failure path. No exact fixed package versions were provided in the input, so use the fixed kernel versions or errata supplied by the relevant Linux distribution or appliance vendor. Prioritize systems that load the rbd module, run Ceph clients, host RBD-backed workloads, or allow delegated storage mapping. If immediate patching is not possible, reduce exposure by disabling or blacklisting the rbd kernel module where unused, restricting access to RBD mapping tools and /sys/bus/rbd/add_single_major, removing unnecessary Ceph client credentials from general-purpose hosts, limiting CAP_SYS_ADMIN or equivalent storage-management privileges, and monitoring for memory-pressure or repeated failed RBD mapping attempts. Do not rely on mitigation alone for systems that require RBD; patching is the durable fix.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the RBD error-path fix. Validate with the distribution package manager, kernel changelog, vendor advisory, or source patch history rather than only checking the base upstream version string. Reboot into the fixed kernel and verify the active kernel with uname -r. On systems where RBD is not required, verify the rbd module is not loaded and cannot be auto-loaded. On systems where RBD is required, confirm only authorized administrators or service accounts can perform RBD mapping and that /sys/bus/rbd/add_single_major is not writable by untrusted users. Avoid reproducing the fault on production systems; if validation testing is necessary, perform it in an isolated lab with kernel debugging/fault-injection enabled and confirm that repeated failed RBD add attempts no longer produce KASAN, Oops, or panic reports.

Typical attack path

1. Gain local authenticated access to a Linux host with the vulnerable kernel and the rbd module available or loaded.
2. Obtain sufficient permission to map Ceph RBD devices or write to the kernel RBD add interface.
3. Initiate an RBD device add operation through the sysfs RBD interface or an equivalent mapping tool.
4. Trigger or coincide with a failure in device_add_disk() after device_add() succeeds, for example through resource exhaustion or controlled fault-injection conditions.
5. The vulnerable cleanup path frees disk state twice and re-enters block multi-queue teardown incorrectly.
6. The kernel hits a NULL-pointer dereference/general protection fault and the host may panic, reboot, or lose service availability.

How to detect it

Look for evidence of attempted or successful triggering in kernel logs, system journal, crash dumps, audit logs, and storage orchestration logs. Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, kdump/vmcore records, auditd syscall/file-watch events, Ceph client logs, and automation logs that invoke rbd map or write to the RBD sysfs add interface. Indicators include kernel Oops or panic messages showing NULL-pointer dereference or general protection fault in __blk_mq_free_map_and_rqs(), call traces containing blk_mq_free_tag_set() and do_rbd_add(), KASAN reports during RBD device add, repeated writes to /sys/bus/rbd/add_single_major, and unusual bursts of failed RBD map/add operations. Because this issue is a crash/DoS bug, post-exploitation artifacts are usually kernel crash evidence and triggering activity rather than persistent malware. Correlate crash timestamps with local users, sudo/session logs, audit events, Ceph credentials used, rbd CLI invocations, and memory-pressure/resource-exhaustion events.

• /sys/bus/rbd/add_single_major
• __blk_mq_free_map_and_rqs
• blk_mq_free_tag_set
• do_rbd_add
• rbd_free_disk
• device_add_disk
• KASAN: null-ptr-deref
• Oops: general protection fault
• NULL pointer dereference
• general protection fault, probably for non-canonical address
• Comm: bash
• kernfs_fop_write_iter
• vfs_write
• ksys_write
• rbd map
• modprobe rbd
• rbd:

What your security team should do

• Inventory Linux hosts that use Ceph RBD or have the rbd kernel module loaded, and prioritize those for kernel updates.
• Patch affected systems with the vendor kernel containing the RBD cleanup fix; schedule reboots because the running kernel must be replaced.
• Restrict RBD mapping privileges to trusted administrators and service accounts only; review access to storage orchestration tools that can map RBD devices.
• If RBD is unused, blacklist or disable the rbd module and verify it cannot be loaded automatically.
• Add monitoring for kernel Oops, panic, KASAN, and block multi-queue cleanup errors involving rbd, do_rbd_add, blk_mq_free_tag_set, or __blk_mq_free_map_and_rqs.
• Review audit logs for unexpected writes to /sys/bus/rbd/add_single_major or repeated RBD map/add attempts.
• Treat any crash matching this stack trace as a potential local denial-of-service attempt or unsafe storage automation behavior and preserve kernel logs for investigation.