CVE-2026-90184: null_blk: serialize configfs attribute updates with device setup
In the Linux kernel, the following vulnerability has been resolved:
nullblk: serialize configfs attribute updates with device setup
The attribute store methods generated with NULLBDEVICEATTR() refuse to change the configuration of a live device by testing NULLBDEVFLCONFIGURED, but that flag is only set by nullbdevicepowerstore() after nulladddev() 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 nulladddev() and change the device configuration while it is being used.
nulladddev() 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 nullbdevicepowerstore() mutexlock(&lock) nulladddev() if (dev->zoned) -> false / no BLKFEATZONED / nullbdevicezonedstore() testbit(FLCONFIGURED) -> 0 dev->zoned = true blkmqallocdisk() / queue is not zoned / if (nullb->dev->zoned) -> true nullregisterzoneddev() blkrevalidatediskzones()
blkrevalidatediskzones() is then called for a queue that does not have BLKFEATZONED set, which triggers its WARNONONCE() and fails the device setup with -EIO:
WARNING: CPU: 2 PID: 322 at block/blk-zoned.c:2357 blkrevalidatediskzones+0x4c/0x560
Clearing dev->zoned in the same window is worse: the queue is created with BLKFEATZONED but the zone resources are never initialized, so adddisk() 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 nullprocesszonedcmd() dereferences on the first write.
Fix this by taking the global lock, which nullbdevicepowerstore() already holds across nulladddev() and nulldeldev(), around both the NULLBDEVFLCONFIGURED test and the update of the device configuration. The submitqueues and pollqueues 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 configfsregistersubsystem() returns, that is, before nullinit() gets to mutexinit(&lock), also initialize the lock statically with DEFINEMUTEX().
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch NULLB_DEV_FL_CONFIGURED - Compensating control
If running kernels affected by a NULLB zoned-device configuration race (NULLB_DEV_FL_CONFIGURED / BLK_FEAT_ZONED), mitigate the concurrency by serializing configfs attribute writes to the NULLB device setup path so that zoned/power (e.g., nullb0/zoned and nullb0/power) cannot be updated concurrently while the device is being added/revalidated.
Event History
Frequently Asked Questions
Who is exposed to this race condition?
Systems using null_blk devices through configfs are exposed when configuration attributes can be written while a device is being set up. The described race involves concurrent writes to the power and zoned attributes.
What does an attacker or local user need to trigger it?
They need the ability to write null_blk configfs attributes and to perform a configuration update concurrently with device creation through the power attribute. Writes to different configfs attribute files are not serialized by configfs.
What can be done if the fix cannot be applied immediately?
Avoid changing null_blk configuration attributes while a device is being brought up, and serialize device setup and all attribute updates externally. In particular, do not allow concurrent writes to power and attributes such as zoned.
How can I determine whether a system may have encountered the issue?
Review null_blk configfs operations for overlapping writes during device setup, especially a power write occurring at the same time as a zoned write. The affected sequence can leave queue setup based on one zoned value while zone resources are initialized based on another.