CVE-2026-90185 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
null_blk: serialize configfs attribute stores with the lock
The NULLB_DEVICE_ATTR _store takes no lock: apply_fn attributes (submit_queues, poll_queues) get dev->NAME written again after apply_fn returns, outside its lock; APPLY=NULL attributes are entirely lockless. configfs only serializes stores per-open-file, so concurrent stores on separate fds race.
For apply_fn attributes, once one store's apply_fn has reconfigured the hardware, a second (losing) store can still overwrite dev->NAME afterwards. This leaves dev->submit_queues out of sync with the live queue count, which is later caught by the WARN_ON_ONCE() in null_map_queues().
For !apply_fn attributes, power_store()'s null_add_dev() validates and builds the device under "lock" but only sets CONFIGURED afterwards. A store slipping in during this window can change a field mid-setup -- for example, zone_nr_conv can be pushed above nr_zones after it has already been clamped, leading to an out-of-bounds dev->zones[] access.
Take "lock" in the macro around the apply_fn call, the CONFIGURED test and the field write, and move it out of nullb_apply_submit_queues()/ nullb_apply_poll_queues() so both paths are covered once. This serializes stores with power_store's setup and with each other.
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 vulnerability in the null_blk driver represents a critical concurrency flaw rooted in improper synchronization mechanisms within its configuration file system interface. The core issue stems from the lack of adequate locking when handling configfs attribute store operations, specifically affecting how device configurations are applied and persisted to hardware state. In this architecture, configfs inherently serializes write operations only on a per-open-file descriptor basis, which fails to protect against race conditions arising from concurrent stores initiated through separate file descriptors by different processes or threads. This architectural gap allows multiple configuration updates to proceed simultaneously without mutual exclusion, leading to data corruption and potential kernel instability when the underlying hardware state is modified concurrently with ongoing setup procedures.
For attributes that utilize an apply function, such as submit_queues and poll_queues, the vulnerability manifests through a specific race condition involving device naming and queue synchronization. When one store operation invokes its apply function to reconfigure the hardware queues, it successfully updates the live system state. However, subsequent logic writes the dev->NAME attribute after the apply function returns but outside of any protective lock context. If a second store operation is in progress concurrently, particularly if it loses the race for initial resource allocation or configuration priority, it may still proceed to overwrite dev->NAME after the first operation has already altered the hardware state. This desynchronization results in dev->submit_queues becoming inconsistent with the actual live queue count maintained by the kernel. The discrepancy eventually triggers a WARN_ON_ONCE assertion within null_map_queues(), indicating that internal data structures no longer reflect reality, which can lead to unpredictable behavior or denial of service conditions as the driver attempts to operate on stale or conflicting state information.
The vulnerability is further exacerbated in attributes that do not utilize an apply function, such as power_store operations. In these cases, the device setup process involves validating parameters and building the device structure while holding a lock, but the final step of marking the device as CONFIGURED occurs after this critical section. This creates a temporal window where the configuration is partially applied yet not fully committed or protected from external modification. A concurrent store operation can slip into this gap and modify fields mid-setup. For instance, in zone-based storage configurations, an attacker or misconfigured application could alter the zone_nr_conv parameter to exceed nr_zones after it has already been clamped during validation. This specific race condition leads directly to out-of-bounds memory access within dev->zones[], posing a severe risk of kernel panic, privilege escalation, or arbitrary code execution depending on how the invalid pointer is subsequently dereferenced by other subsystems interacting with null_blk devices.
To mitigate this vulnerability, the fix involves restructuring the locking granularity around configfs attribute stores to ensure atomicity across both apply and non-apply paths. The solution introduces a lock that encompasses not only the application of configuration changes but also the validation checks and the finalization steps such as setting the CONFIGURED flag or writing device names. By moving this synchronization mechanism out of specific helper functions like nullb_apply_submit_queues and nullb_apply_poll_queues, the patch ensures that all store operations are serialized consistently with each other and with the initial setup phase in power_store. This comprehensive locking strategy eliminates the race windows where concurrent modifications could corrupt state or cause invalid memory accesses. From a security standards perspective, this flaw aligns with CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, as it involves multiple execution paths accessing shared kernel data structures without proper mutual exclusion. Furthermore, the potential for out-of-bounds access via zone_nr_conv manipulation relates to CWE-125 Out-of-bounds Read and CWE-787 Out-of-bounds Write, highlighting the importance of rigorous boundary checks combined with robust concurrency controls in kernel-space drivers handling user-configurable parameters.