CVE-2026-90184

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().