CVE-2026-90229: nvme-apple: Destroy the admin queue on removal
In the Linux kernel, the following vulnerability has been resolved:
nvme-apple: Destroy the admin queue on removal
The admin queue is allocated with blkmqallocqueue() but never destroyed. nvmefreectrl() only drops the last reference and blkmqexitqueue() and blksyncqueue() never run: the hctx is never moved to q->unusedhctxlist and the timeout timer and work stay armed on a queue that is about to be freed which will eventually oops inside blkmqtimeoutwork().
This can only be triggered when the controller fails to come up and is then immediately torn down again which is why no one ever ran into this before.
Let's just copy what the pcie driver does: unquiesce and destroy the admin queue before nvmeuninitctrl().
With this the following WARN followed by a panic no longer happens:
WARNING: block/blk-mq.c:4390 at blkmqrelease+0x194/0x238, CPU#4: kworker/u34:4/119 CPU: 4 UID: 0 PID: 119 Comm: kworker/u34:4 Not tainted 7.2.0-rc1-dirty #248 PREEMPT Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: nvme-wq applenvmeremovedeadctrlwork pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : blkmqrelease+0x194/0x238 lr : blkmqrelease+0x58/0x238 sp : ffffc000833a3b50 x29: ffffc000833a3b50 x28: ffff80001d0450f8 x27: ffff800020c95200 x26: 0000000000000088 x25: 0000000000000000 x24: ffff800020f36805 x23: 0000000000000000 x22: ffffc00081a86878 x21: ffff800020be9c60 x20: 0000000000000000 x19: ffff800022501698 x18: 000000000000000a x17: 7365757165722066 x16: 666f7265776f7020 x15: 0000000000000000 x14: 0000000000000028 x13: 0000000000004def x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000805b4fc8 x8 : ffffc00081915820 x7 : ffffc00081c4f3c8 x6 : 0000000000000001 x5 : 0000000000000004 x4 : ffff800022498d80 x3 : ffffc000833a3b14 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800022501698 Call trace: blkmqrelease+0x194/0x238 (P) blkputqueue+0x8c/0xf0 nvmefreectrl+0x4c/0x260 devicerelease+0x44/0x128 kobjectput+0xa0/0x120 putdevice+0x1c/0x40 nvmeuninitctrl+0x48/0x60 applenvmeremove+0x54/0xb0 platformremove+0x28/0x40 deviceremove+0x54/0x98 devicereleasedriverinternal+ devicereleasedriver+0x20/0x38 applenvmeremovedeadctrlwor processonework+0x1f4/0x770 workerthread+0x1b8/0x360 kthread+0x140/0x160 retfromfork+0x10/0x20 irq event stamp: 448 hardirqs last enabled at (447):inunlockirqrestore+0x74/0x80 hardirqs last disabled at (448): [<ffffc000811cf5c0>] el1brk64+0x20/0x60 softirqs last enabled at (0): [ess+0xb28/0x2698 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 0000000000000000 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagA GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [0000000000000000] user address Internal error: Oops: 0000000096000005 [#1] SMP CPU: 7 UID: 0 PID: 54 Comm: kwor 7.2.0-rc1-dirty #248PREEMPT Tainted: [W]=WARN Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: kblockd blkmqtimeou pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : percpureftrygetmany.cons lr : percpureftrygetmany.constprop.0+0xc0/0x168 sp : ffffc000829cbce0 x29: ffffc000829cbce0 x28: ffff800020be9f48 x27: ffff800013e503c0 x26: 0000000000000108 x25: 000009c05 x23: 0000000000000000 x22: ffffc000819f5000 x21: ffff800020be9f48 x20: ffff8001deda4808 x19: ffff8000a x17: 00000000580e1fac x16: ffffc00082bbbb7c x15: 0000000000000000 x14: 0000000000000028 x13: 000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000829cbc20 x8 : ---truncated---
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this failure path?
Systems using the Linux nvme-apple driver are affected only when an NVMe controller fails to come up and is then immediately torn down. The reported failure occurred on an Apple Mac mini (M1, 2020).
What symptoms indicate that this issue has been hit?
A WARNING in block/blk-mq.c at blk_mq_release may be followed by a kernel panic. The failure can eventually oops in blk_mq_timeout_work because timeout timer and work remain armed on a queue being freed.
What change addresses the teardown problem?
The fix unquiesces and destroys the admin queue before nvme_uninit_ctrl() runs. This ensures the queue's block multiqueue cleanup, including timeout-related cleanup, is performed.