PatchSiren cyber security CVE debrief
CVE-2026-46079 Linux CVE debrief
A null-pointer dereference vulnerability exists in the Linux kernel's RBD (RADOS Block Device) driver. The flaw occurs in the error handling path of `do_rbd_add()` when `device_add_disk()` fails after `device_add()` has already succeeded. In this scenario, `rbd_free_disk()` is called twice—once directly in the error path and again through `rbd_dev_device_release()`—leading to a double teardown that corrupts blk-mq state and triggers a null-pointer dereference in `__blk_mq_free_map_and_rqs()` during `blk_mq_free_tag_set()` cleanup. The vulnerability was identified by an experimental kernel memory-management analysis tool and reproduced on kernel v7.0 with KASAN and CONFIG_FAILSLAB enabled, using failslab injection confined to the `__add_disk()` range during RBD image mapping. The fix ensures proper teardown ordering by calling `device_del()` before `rbd_dev_device_release()` when `device_add_disk()` fails, preventing the re-entrant disk cleanup path.
- Vendor
- Linux
- Product
- Unknown
- CVSS
- Unknown
- CISA KEV
- Not listed in stored evidence
- Original CVE published
- 2026-05-27
- Original CVE updated
- 2026-05-27
- Advisory published
- 2026-05-27
- Advisory updated
- 2026-05-27
Who should care
Organizations running Linux kernels with RBD/Ceph storage configurations, particularly those in virtualized or cloud environments where block device hot-add operations may fail under resource pressure. Kernel maintainers and distribution security teams should prioritize backporting the stable fixes.
Technical summary
The RBD driver's `do_rbd_add()` function publishes the device via `device_add()` before attempting `device_add_disk()`. If the latter fails, the error handling incorrectly invokes `rbd_free_disk()` directly and then falls through to `rbd_dev_device_release()`, which calls `rbd_free_disk()` again. This double invocation leaves blk-mq tag set cleanup operating on invalid state, causing a null-pointer dereference in `__blk_mq_free_map_and_rqs()`. The fix reorders cleanup to call `device_del()` before `rbd_dev_device_release()`, ensuring the teardown sequence remains consistent and preventing re-entrant disk cleanup.
Defensive priority
medium
Recommended defensive actions
- Apply the stable kernel patches referenced in the source commits to affected systems running RBD with Ceph storage backends.
- Prioritize patching on systems where RBD image mapping operations may encounter resource exhaustion or failure conditions that could trigger the vulnerable error path.
- Monitor kernel logs for KASAN reports or general protection faults in `__blk_mq_free_map_and_rqs()` or `blk_mq_free_tag_set()` as potential indicators of exploitation attempts or accidental triggering.
- Consider enabling KASAN in testing environments to detect similar use-after-free or double-free conditions in block device drivers.
Evidence notes
The vulnerability description and fix details are sourced from the official CVE record and NVD entry. The commit references provided in the source item link to kernel.org stable tree commits containing the patch. The reproduction details—including KASAN stack trace, QEMU x86_64 guest environment, Ceph backend, and failslab injection methodology—are taken directly from the CVE description. No CVSS score or severity rating is currently assigned by NVD (status: Awaiting Analysis).
Official resources
-
CVE-2026-46079 CVE record
CVE.org
-
CVE-2026-46079 NVD detail
NVD
-
Source item URL
nvd_modified
-
Source reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67
-
Source reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67
-
Source reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67
-
Source reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67
-
Source reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67
2026-05-27