CVE-2026-90186 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
null_blk: reject per-device queue resize for shared tag set
When shared_tags is enabled, null_setup_tagset() makes the device use the global tag_set, whose driver_data stays NULL. null_map_queues() therefore falls back to the module-wide g_submit_queues/g_poll_queues instead of any per-device value.
Resizing submit_queues or poll_queues via configfs on such a device calls blk_mq_update_nr_hw_queues() on the shared set, shrinking set->nr_hw_queues. __blk_mq_realloc_hw_ctxs() only grows the q->queue_hw_ctx[] allocation, so on shrink it merely exits and NULLs the
now-excess hctx slots. null_map_queues(), however, keeps mapping CPUs with the unchanged g_submit_queues/g_poll_queues, so mq_map[] ends up pointing
at those NULLed hctx slots. blk_mq_map_swqueue() 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:blk_mq_map_swqueue+0x4db/0x1430
...... [ 460.228977] Call Trace:
[ 460.229175] <TASK>
[ 460.229354] blk_mq_update_nr_hw_queues+0xd49/0x11c0
[ 460.229779] ? __pfx_blk_mq_update_nr_hw_queues+0x10/0x10
[ 460.230200] nullb_update_nr_hw_queues+0x1a9/0x370 [null_blk]
[ 460.230694] nullb_device_submit_queues_store+0xd9/0x170 [null_blk]
[ 460.231190] ? __pfx_nullb_device_submit_queues_store+0x10/0x10 [null_blk]
[ 460.231776] ? configfs_write_iter+0x35c/0x4e0
[ 460.232122] configfs_write_iter+0x286/0x4e0
[ 460.232460] vfs_write+0x52d/0xd00
[ 460.232779] ? __x64_sys_openat+0x108/0x1d0
[ 460.233106] ? __pfx_vfs_write+0x10/0x10
[ 460.233413] ? fdget_pos+0x1cf/0x4c0
[ 460.233745] ? fput_close+0x133/0x190
[ 460.234038] ? __pfx_expand_files+0x10/0x10
[ 460.234368] ksys_write+0xfc/0x1d0
Reproducer: modprobe null_blk shared_tags=1 submit_queues=64 poll_queues=1 mkdir /sys/kernel/config/nullb/dev echo 1 > /sys/kernel/config/nullb/dev/power echo 1 > /sys/kernel/config/nullb/dev/submit_queues
A per-device resize of a shared tag set is meaningless anyway, so reject it with -EINVAL in nullb_update_nr_hw_queues() when the device is bound to the global tag_set.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel vulnerability identified within the null_blk block driver represents a critical local denial-of-service condition triggered by improper handling of shared hardware queue configurations during runtime resizing operations. This flaw specifically affects systems where the null_blk module is loaded with the shared_tags parameter enabled, which causes devices to utilize a global tag set rather than maintaining independent per-device structures. The root cause lies in an inconsistency between how hardware context allocations are managed versus how CPU-to-queue mappings are maintained when reducing the number of submit or poll queues via the configfs interface. When an administrator attempts to resize these queue parameters on such a device, the kernel invokes blk_mq_update_nr_hw_queues() to adjust the shared tag set's count of hardware queues. While this function correctly handles growth by reallocating context structures, it fails to properly handle shrinkage for shared sets because __blk_mq_realloc_hw_ctxs() is designed only to grow allocations and exits early when shrinking, merely nullifying excess hctx slots without updating the associated mapping arrays.
The operational impact of this logic error manifests as a kernel panic due to a NULL pointer dereference within blk_mq_map_swqueue(). Because the hardware context array has been partially cleared but the CPU-to-queue mapping remains unchanged, mq_map[] continues to reference CPUs that are now mapped to NULLed hctx slots. When the kernel subsequently attempts to access hctx->cpumask during software queue mapping, it dereferences a null pointer, resulting in an immediate system crash as evidenced by KASAN reports indicating memory access violations at specific offsets within the hardware context structure. This vulnerability allows any local user with write permissions to the relevant configfs paths to destabilize the entire host system, effectively achieving a denial-of-service without requiring elevated privileges beyond standard file system interaction capabilities. The attack vector is straightforward and reliable, involving only the modification of queue count parameters through standard configuration interfaces after initializing the device with shared tags enabled.
From a vulnerability classification perspective, this issue aligns closely with CWE-476, which denotes NULL Pointer Dereference vulnerabilities arising from improper checks before pointer usage. Additionally, it relates to CWE-823 regarding Object Reference Using Inconsistent Size or Type, as the internal state of the hardware context array becomes inconsistent with the mapping tables that reference those objects. In terms of adversarial tactics, this vulnerability supports ATT&CK technique T1053 Scheduled Task/Job, specifically through file system manipulation to trigger kernel instability, and can be leveraged for privilege escalation if combined with other local exploits or used as a disruptive vector in multi-tenant environments where availability is paramount. The lack of validation on per-device resize requests against the shared nature of the underlying tag set represents a fundamental design oversight in how dynamic reconfiguration interacts with global resource management within the block layer subsystem.
Mitigation strategies for this vulnerability primarily involve applying the upstream kernel patch that introduces explicit validation checks within nullb_update_nr_hw_queues(). By detecting when a device is bound to the global shared tag set, the driver can reject any attempt to resize submit or poll queues by returning an EINVAL error code, thereby preventing the inconsistent state from ever being reached. Until such patches are applied and deployed across affected systems, administrators should avoid configuring null_blk devices with shared_tags enabled if dynamic queue resizing via configfs is required. Alternatively, disabling the ability to modify these parameters post-initialization through restrictive file permissions on the specific configfs entries can serve as a temporary compensating control. Organizations relying on virtualized block storage backends or testing environments utilizing null_blk must ensure their kernel versions include this fix to maintain system stability and prevent local denial-of-service attacks stemming from configuration manipulation.