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