null_blk: serialize configfs attribute updates with device setup
Summary
| CVE | CVE-2026-90184 |
| State | PUBLISHED |
| Assigner | Linux |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-09-17 17:17:12 UTC |
| Updated | 2026-09-17 17:17:12 UTC |
| Description | 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(). |
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|
| CNA |
Linux |
Linux |
affected 3bf2bd20734e3e6ffda53719a9c10fb3ee9c5ffa 6352e7ead2d8111802a554eeb94886f5a9894bb9 git |
Not specified |
| CNA |
Linux |
Linux |
affected 3bf2bd20734e3e6ffda53719a9c10fb3ee9c5ffa 7de792b4c48fba02a36a8077032f7d5093c925e5 git |
Not specified |
| CNA |
Linux |
Linux |
affected 3bf2bd20734e3e6ffda53719a9c10fb3ee9c5ffa aed8af338a09a64d63b068a803c4ecfc5701dd4c git |
Not specified |
| CNA |
Linux |
Linux |
affected 3bf2bd20734e3e6ffda53719a9c10fb3ee9c5ffa 32456a85995579e56c60cc53c357cda75a9d4f7c git |
Not specified |
| CNA |
Linux |
Linux |
affected 3bf2bd20734e3e6ffda53719a9c10fb3ee9c5ffa d3d35dd045a35991bf6fd13de5f293e6dd7bf3b3 git |
Not specified |
| CNA |
Linux |
Linux |
affected 3bf2bd20734e3e6ffda53719a9c10fb3ee9c5ffa 4e1f23f9c33c156be7e313b40695af5a3a834739 git |
Not specified |
| CNA |
Linux |
Linux |
affected 4.14 |
Not specified |
| CNA |
Linux |
Linux |
unaffected 4.14 semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.1.188 6.1.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.6.157 6.6.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.12.110 6.12.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 6.18.52 6.18.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.2.6 7.2.* semver |
Not specified |
| CNA |
Linux |
Linux |
unaffected 7.3-rc1 * original_commit_for_fix |
Not specified |
References
| Reference | Source | Link | Tags |
|---|
| git.kernel.org/stable/c/7de792b4c48fba02a36a8077032f7d5093c925e5 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/d3d35dd045a35991bf6fd13de5f293e6dd7bf3b3 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/32456a85995579e56c60cc53c357cda75a9d4f7c |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/4e1f23f9c33c156be7e313b40695af5a3a834739 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/aed8af338a09a64d63b068a803c4ecfc5701dd4c |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/6352e7ead2d8111802a554eeb94886f5a9894bb9 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| CVE Program record |
CVE.ORG |
www.cve.org |
canonical |
| NVD vulnerability detail |
NVD |
nvd.nist.gov |
canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.