CVE-2026-90184 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
null_blk: serialize configfs attribute updates with device setup
The attribute store methods generated with NULLB_DEVICE_ATTR() refuse to change the configuration of a live device by testing NULLB_DEV_FL_CONFIGURED, but that flag is only set by nullb_device_power_store() after null_add_dev() has returned, and the store methods take no lock at all. configfs only serializes writes to the same open file (buffer->mutex), so a write to any attribute can run concurrently with null_add_dev() and change the device configuration while it is being used.
null_add_dev() reads the configuration several times, e.g. dev->zoned is read once to set up the queue limits and once to initialize the zone resources:
CPU0: echo 1 > nullb0/power CPU1: echo 1 > nullb0/zoned nullb_device_power_store() mutex_lock(&lock) null_add_dev() if (dev->zoned) -> false /* no BLK_FEAT_ZONED */ nullb_device_zoned_store() test_bit(FL_CONFIGURED) -> 0 dev->zoned = true blk_mq_alloc_disk() /* queue is not zoned */ if (nullb->dev->zoned) -> true null_register_zoned_dev() blk_revalidate_disk_zones()
blk_revalidate_disk_zones() is then called for a queue that does not have BLK_FEAT_ZONED set, which triggers its WARN_ON_ONCE() and fails the device setup with -EIO:
WARNING: CPU: 2 PID: 322 at block/blk-zoned.c:2357 blk_revalidate_disk_zones+0x4c/0x560
Clearing dev->zoned in the same window is worse: the queue is created with BLK_FEAT_ZONED but the zone resources are never initialized, so add_disk() succeeds for a zoned disk that has no zones. And a store that lands after the last dev->zoned test leaves dev->zoned set while dev->zones is still NULL, which null_process_zoned_cmd() dereferences on the first write.
Fix this by taking the global lock, which nullb_device_power_store() already holds across null_add_dev() and null_del_dev(), around both the NULLB_DEV_FL_CONFIGURED test and the update of the device configuration. The submit_queues and poll_queues apply callbacks are now called with that lock held, so remove the locking they did themselves.
Since the store methods can run as soon as configfs_register_subsystem() returns, that is, before null_init() gets to mutex_init(&lock), also initialize the lock statically with DEFINE_MUTEX().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel driver for NULL block devices contains a critical race condition vulnerability arising from insufficient synchronization during device configuration updates. The core issue stems from the lack of atomicity when modifying device attributes via configfs while the underlying block device is being initialized or torn down. Specifically, the attribute store methods generated by the NULLB_DEVICE_ATTR macro attempt to prevent changes to live devices by checking a configured flag, but this check and the subsequent configuration update are not protected by any locking mechanism. Meanwhile, the global lock that ensures safe transitions between device states is only held during specific power state operations, leaving a window where concurrent writes can corrupt internal data structures. This architectural flaw allows user-space processes to modify critical device parameters such as zoned storage settings at inopportune moments, leading to undefined behavior and potential kernel crashes.
The operational impact of this vulnerability manifests primarily through race conditions between the initialization sequence null_add_dev() and attribute store operations like nullb_device_zoned_store(). During device setup, the driver reads configuration flags multiple times to set up queue limits and initialize zone resources. If a user-space process writes to an attribute such as zoned status while null_add_dev is executing, it can observe stale or partially updated state values. For instance, if the system detects that the device should be zoned after initial checks but before full initialization, subsequent calls to blk_revalidate_disk_zones may occur on a queue that lacks the necessary BLK_FEAT_ZONED feature flag. This mismatch triggers kernel warnings and results in an I/O error during disk registration, effectively preventing the device from functioning correctly or causing immediate instability depending on timing.
In more severe scenarios, this race condition can lead to memory corruption and kernel panics due to null pointer dereferences. If a configuration update clears the zoned flag after queue creation but before zone resource initialization completes, the block layer may proceed with add_disk for a device that claims to be zoned but has no actual zones defined. Conversely, if an update sets the zoned flag while dev->zones remains NULL because initialization is incomplete, subsequent write operations processed by null_process_zoned_cmd will attempt to dereference this uninitialized pointer. This results in a kernel oops or panic, compromising system stability and availability. The vulnerability effectively allows local users with access to configfs interfaces to destabilize the host system through carefully timed concurrent writes.
To mitigate this risk, the fix involves enforcing strict serialization of all configuration attribute updates by wrapping both the configured flag check and the actual state modification within the existing global device lock. This ensures that no configuration changes can occur while null_add_dev or null_del_dev are executing, as these functions already hold the necessary locks for their respective operations. Additionally, callbacks responsible for submitting queues must be invoked under this same lock to maintain consistency across all subsystems interacting with the block device. A critical aspect of this remediation is addressing a timing issue where configfs registers attributes before the driver has initialized its mutex. To resolve this, the global lock is statically defined using DEFINE_MUTEX rather than being dynamically initialized later in null_init. This guarantees that the synchronization primitive is available immediately upon subsystem registration, preventing any early concurrent access from bypassing protection mechanisms.
From a security classification perspective, this vulnerability aligns with CWE-362 Concurrent Execution Using Shared Resource with Improper Synchronization Race Conditions. The root cause lies in the failure to properly serialize access to shared state variables during critical initialization phases. In terms of attack vectors and techniques, this relates to ATT&CK technique T1059 Command and Scripting Interpreter via configfs interactions, where an attacker leverages system configuration interfaces to manipulate kernel behavior. While typically requiring local privilege escalation or specific device node permissions, the severity is heightened by the potential for denial-of-service through kernel panic. System administrators should ensure that Linux kernels are updated with patches addressing this null_blk synchronization issue and restrict access to configfs devices to trusted users only until all systems are patched.