UBUNTU-CVE-2026-90186: Low severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: nullblk: reject per-device queue resize for shared tag set When sharedtags is enabled, nullsetuptagset() makes the device use the global tagset, whose driverdata stays NULL. nullmapqueues() therefore falls back to the module-wide gsubmitqueues/gpollqueues instead of any per-device value. Resizing submitqueues or pollqueues via configfs on such a device calls blkmqupdatenrhwqueues() on the shared set, shrinking set->nrhwqueues. blkmqreallochwctxs() only grows the q->queuehwctx[] allocation, so on shrink it merely exits and NULLs the now-excess hctx slots. nullmapqueues(), however, keeps mapping CPUs with the unchanged gsubmitqueues/gpollqueues, so mqmap[] ends up pointing at those NULLed hctx slots. blkmqmapswqueue() then dereferences the NULL hctx (hctx->cpumask), crashing the kernel: [ 460.218374] KASAN: null-ptr-deref in range [0x0000000000000098-0x000000000000009f] [ 460.219003] CPU: 24 UID: 0 PID: 1492 Comm: sh Not tainted 7.2.0-rc2+ #67 PREEMPT(full) [ 460.219792] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 [ 460.220452] RIP: 0010:blkmqmapswqueue+0x4db/0x1430 ...... [ 460.228977] Call Trace: [ 460.229175] <TASK> [ 460.229354] blkmqupdatenrhwqueues+0xd49/0x11c0 [ 460.229779] ? pfxblkmqupdatenrhwqueues+0x10/0x10 [ 460.230200] nullbupdatenrhwqueues+0x1a9/0x370 [nullblk] [ 460.230694] nullbdevicesubmitqueuesstore+0xd9/0x170 [nullblk] [ 460.231190] ? pfxnullbdevicesubmitqueuesstore+0x10/0x10 [nullblk] [ 460.231776] ? configfswriteiter+0x35c/0x4e0 [ 460.232122] configfswriteiter+0x286/0x4e0 [ 460.232460] vfswrite+0x52d/0xd00 [ 460.232779] ? x64sysopenat+0x108/0x1d0 [ 460.233106] ? pfxvfswrite+0x10/0x10 [ 460.233413] ? fdgetpos+0x1cf/0x4c0 [ 460.233745] ? fputclose+0x133/0x190 [ 460.234038] ? pfxexpandfiles+0x10/0x10 [ 460.234368] ksyswrite+0xfc/0x1d0 Reproducer: modprobe nullblk sharedtags=1 submitqueues=64 pollqueues=1 mkdir /sys/kernel/config/nullb/dev echo 1 > /sys/kernel/config/nullb/dev/power echo 1 > /sys/kernel/config/nullb/dev/submitqueues A per-device resize of a shared tag set is meaningless anyway, so reject it with -EINVAL in nullbupdatenrhwqueues() when the device is bound to the global tagset.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In null_blk, reject per-device submit_queues or poll_queues resizing with -EINVAL in nullb_update_nr_hw_queues() when the device is bound to the global shared tag_set.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the null_blk driver with shared_tags enabled are exposed if submit_queues or poll_queues are resized on an individual device through configfs. The listed Ubuntu kernel packages include linux, linux-realtime, linux-azure, linux-gcp, linux-azure-fde, linux-gke, linux-riscv, and linux-gkeop.
What action triggers the crash?
The crash is triggered by resizing a null_blk device's submit_queues or poll_queues while it uses the shared global tag set. The resize can shrink the shared tag set while CPU queue mapping still uses the module-wide queue counts, causing a mapping to a NULL hardware context.
What can be done if an update cannot be installed immediately?
Do not change submit_queues or poll_queues through configfs for null_blk devices configured with shared_tags. Avoid per-device queue resizing until the kernel fix is available.
How can administrators recognize that this issue has occurred?
The kernel can crash with a NULL-pointer dereference in blk_mq_map_swqueue() while accessing hctx->cpumask. The provided example reports KASAN null-ptr-deref at an address range beginning near 0x98.