CVE-2026-90185: null_blk: serialize configfs attribute stores with the lock
In the Linux kernel, the following vulnerability has been resolved:
nullblk: serialize configfs attribute stores with the lock
The NULLBDEVICEATTR store takes no lock: applyfn attributes (submitqueues, pollqueues) get dev->NAME written again after applyfn 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 applyfn attributes, once one store's applyfn has reconfigured the hardware, a second (losing) store can still overwrite dev->NAME afterwards. This leaves dev->submitqueues out of sync with the live queue count, which is later caught by the WARNONONCE() in nullmapqueues().
For !applyfn attributes, powerstore()'s nulladddev() 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, zonenrconv can be pushed above nrzones after it has already been clamped, leading to an out-of-bounds dev->zones[] access.
Take "lock" in the macro around the applyfn call, the CONFIGURED test and the field write, and move it out of nullbapplysubmitqueues()/ nullbapplypollqueues() so both paths are covered once. This serializes stores with powerstore's setup and with each other.
Event History
Frequently Asked Questions
Who is exposed to this race condition?
Systems using the null_blk driver and changing its configfs attributes are exposed when stores can occur concurrently through separate file descriptors. Configfs serializes stores only per open file, not across separate opens.
What does an attacker or triggering process need to do?
It needs the ability to perform concurrent configfs attribute writes for a null_blk device using separate file descriptors. The race affects both attributes that invoke apply functions, such as submit_queues and poll_queues, and attributes without an apply function.
What are the observable consequences of a successful race?
Concurrent updates can leave dev->submit_queues inconsistent with the live queue count, which can trigger WARN_ON_ONCE() in null_map_queues(). During device setup, a raced update such as zone_nr_conv can exceed the previously clamped nr_zones value and cause an out-of-bounds dev->zones[] access.