CVE-2026-46079: rbd: fix null-ptr-deref when device_add_disk() fails
In the Linux kernel, the following vulnerability has been resolved:
rbd: fix null-ptr-deref when deviceadddisk() fails
dorbdadd() publishes the device with deviceadd() before calling deviceadddisk(). If deviceadddisk() fails after deviceadd() succeeds, the error path calls rbdfreedisk() directly and then later falls through to rbddevdevicerelease(), which calls rbdfreedisk() again. This double teardown can leave blk-mq cleanup operating on invalid state and trigger a null-ptr-deref in blkmqfreemapandrqs(), reached from blkmqfreetagset().
Fix this by following the normal remove ordering: call devicedel() before rbddevdevicerelease() when deviceadddisk() fails after deviceadd(). That keeps the teardown sequence consistent and avoids re-entering disk cleanup through the wrong path.
The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available.
We reproduced the bug on v7.0 with a real Ceph backend and a QEMU x8664 guest booted with KASAN and CONFIGFAILSLAB enabled. The reproducer confines failslab injections to the adddisk() range and injects fail-nth while mapping an RBD image through /sys/bus/rbd/addsinglemajor.
On the unpatched kernel, fail-nth=4 reliably triggered the fault:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 UID: 0 PID: 273 Comm: bash Not tainted 7.0.0-01247-gd60bc1401583 #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:blkmqfreemapandrqs+0x8c/0x240 Code: 00 00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85 ed 0f 85 0a 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 e9 48 c1 e9 03 <80> 3c 01 00 0f 85 31 01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00 RSP: 0018:ff1100000ab0fac8 EFLAGS: 00000246 RAX: dffffc0000000000 RBX: ff1100000c4806a0 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: ff1100000c4806f4 RBP: 0000000000000000 R08: 0000000000000001 R09: ffe21c000189001b R10: ff1100000c4800df R11: ff1100006cf37be0 R12: 0000000000000000 R13: 0000000000000000 R14: ff1100000c480700 R15: ff1100000c480004 FS: 00007f0fbe8fe740(0000) GS:ff110000e5851000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe53473b2e0 CR3: 0000000012eef000 CR4: 00000000007516f0 PKRU: 55555554 Call Trace: <TASK> blkmqfreetagset+0x77/0x460 dorbdadd+0x1446/0x2b80 ? pfxdorbdadd+0x10/0x10 ? lockacquire+0x18c/0x300 ? findheldlock+0x2b/0x80 ? sysfsfilekobj+0xb6/0x1b0 ? pfxsysfskfwrite+0x10/0x10 kernfsfopwriteiter+0x2f4/0x4a0 vfswrite+0x98e/0x1000 ? expandfiles+0x51f/0x850 ? pfxvfswrite+0x10/0x10 ksyswrite+0xf2/0x1d0 ? pfxksyswrite+0x10/0x10 dosyscall64+0x115/0x690 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f0fbea15907 Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007ffe22346ea8 EFLAGS: 00000246 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000058 RCX: 00007f0fbea15907 RDX: 0000000000000058 RSI: 0000563ace6c0ef0 RDI: 0000000000000001 RBP: 0000563ace6c0ef0 R08: 0000563ace6c0ef0 R09: 6b6435726d694141 R10: 5250337279762f78 R11: 0000000000000246 R12: 0000000000000058 R13: 00007f0fbeb1c780 R14: ff1100000c480700 R15: ff1100000c480004 </TASK>
With this fix applied, rerunning the reproducer over fail-nth=1..256 yields no KASAN reports.
[ idryomov: rename erroutdevicedel -> erroutdevice ]
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.141.1-1 - Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Fixed in v6.13-rc1 - Configuration
Fix rbd null-ptr-deref by ensuring normal remove ordering: when device_add_disk() fails after device_add(), follow the normal remove ordering by calling device_del() so teardown is consistent and avoids re-entering disk cleanup through the wrong path.
Linux kernel (rbd) device_add_disk() error-path teardown ordering = call device_del() before rbd_dev_device_release() / rbd_free_disk()
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux kernel RBD driver are exposed when adding an RBD-backed disk reaches a device_add_disk() failure after device_add() has succeeded. The issue was reproduced with a real Ceph backend in a QEMU x86_64 guest using KASAN and CONFIG_FAILSLAB.
What must happen for the vulnerability to be triggered?
An attacker or fault condition must cause device_add_disk() to fail during RBD device setup after the device has already been published with device_add(). The resulting error path performs disk teardown twice, which can trigger a null-pointer dereference during blk-mq tag-set cleanup.
Does normal/default operation trigger this reliably?
The provided information only demonstrates reproduction with failure injection via CONFIG_FAILSLAB. It does not establish that ordinary RBD disk creation without an induced device_add_disk() failure will trigger the issue.
What is the impact if triggered?
The failure can cause a kernel null-pointer dereference in __blk_mq_free_map_and_rqs(), reached through blk_mq_free_tag_set(). The reported impact is availability loss; no confidentiality or integrity impact is listed.