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().
Published: 2026-09-17
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Potential kernel panic and device misconfiguration leading to denial of service
Action: Apply patch
AI Analysis

Impact

The null_blk driver in the Linux kernel contains a race condition that permits a concurrently executed configfs attribute write to alter a live block device's configuration. Store functions generated by NULLB_DEVICE_ATTR() lack a lock and postpone setting the NULLB_DEV_FL_CONFIGURED flag until after null_add_dev() returns, so an attacker who can write to the device's configfs attributes can change the zoned or power state while the device is in use. The resulting internal state inconsistency triggers WARN_ON_ONCE in blk_revalidate_disk_zones() or causes a null‑pointer dereference in null_process_zoned_cmd(), leading the kernel to log an error, return -EIO, or in some paths crash, effectively denying service to the device.

Affected Systems

The flaw exists in every Linux kernel that includes the null_blk pseudo block device driver before the commit that introduces a global mutex around configuration changes. It applies to all distributions that ship the in‑tree null_blk module, with no specific version boundaries listed in the advisory.

Risk and Exploitability

The vulnerability has a very low probability of being exploited, as shown by an EPSS score below 1% and the fact that it is not listed in the CISA Known Exploited Vulnerabilities catalog. It requires the ability to write to configfs attributes—normally root or a privileged user—and is not remotely exploitable. Although the flaw can cause kernel panic or device failure, the overall risk is limited to systems with broad configuration access.

Generated by OpenCVE AI on September 20, 2026 at 01:46 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that incorporates the null_blk lock fix, as provided in the latest mainline or distribution patch.
  • If a kernel upgrade cannot be performed immediately, restrict write access to the null_blk configuration files in /sys/kernel/config or unmount the configfs filesystem to prevent concurrent configuration changes.
  • Rebuild the kernel to ensure the global lock in null_blk is initialized statically with DEFINE_MUTEX, and verify that the lock is enabled in the compiled configuration.
  • Reboot the system after the update to clear any stale state and ensure the fix is active.

Generated by OpenCVE AI on September 20, 2026 at 01:46 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Sun, 20 Sep 2026 02:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
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().
Title null_blk: serialize configfs attribute updates with device setup
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-17T16:07:07.728Z

Reserved: 2026-09-11T19:38:34.791Z

Link: CVE-2026-90184

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:17:12.833

Modified: 2026-09-17T17:17:12.833

Link: CVE-2026-90184

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-20T02:00:13Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')