CVE-2026-90184 json
null_blk: serialize configfs attribute updates with device setup
published 2026-09-17 53 d ago modified 2026-10-19 21 d ago also EUVD-2026-81777
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.2%
- EPSS 0.2% chance of exploitation in 30 days, percentile 10%
- public exploits
- 0
- none known
Summary
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().
Patch / fix
- Linux Linux 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6, 7.3
- linux Debian 12 6.1.190-1
- linux Debian 13 6.12.111-1
- linux Debian 14 7.2.6-1
- linux-6.12 Debian 12 6.12.111-1~deb12u1
debian advisories DEBIAN-CVE-2026-90184
- linux Ubuntu 26.04 LTS 7.0.0-42.42
- linux-aws Ubuntu 26.04 LTS 7.0.0-1016.17
- linux-gcp Ubuntu 26.04 LTS 7.0.0-1016.18
- linux-ibm Ubuntu 26.04 LTS 7.0.0-1017.17
- linux-riscv Ubuntu 26.04 LTS 7.0.0-42.42.1
- linux-oracle Ubuntu 26.04 LTS 7.0.0-1015.16
- linux-hwe-7.0 Ubuntu 24.04 LTS 7.0.0-42.42~24.04.1
- linux-oem-7.0 Ubuntu 26.04 LTS 7.0.0-1017.17
ubuntu advisories UBUNTU-CVE-2026-90184
Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
- kernel-source openSUSE Tumbleweed 7.2.8-1.1
opensuse advisories openSUSE-SU-2026:11893-1
- kernel Azure Linux 3.0 6.6.157.1-1
azure linux advisories AZL-102302
Azure Linux vulnerability data, Copyright (c) Microsoft Corporation, from https://github.com/microsoft/AzureLinuxVulnerabilityData via OSV, under the MIT licence; changed: normalised to fixed package versions per release. MIT
- git.kernel.org/stable/c/6352e7ead2d8111802a554eeb94886f5a9894bb9 commit
- git.kernel.org/stable/c/7de792b4c48fba02a36a8077032f7d5093c925e5 commit
- git.kernel.org/stable/c/aed8af338a09a64d63b068a803c4ecfc5701dd4c commit
- git.kernel.org/stable/c/32456a85995579e56c60cc53c357cda75a9d4f7c commit
- git.kernel.org/stable/c/d3d35dd045a35991bf6fd13de5f293e6dd7bf3b3 commit
- git.kernel.org/stable/c/4e1f23f9c33c156be7e313b40695af5a3a834739 commit
Vendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2026-90184 updated cvss 5.5
kernel: null_blk: serialize configfs attribute updates with device setup
-
Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernel Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-9 Red Hat OpenShift Container Platform 5 openshift/ose-rhel-coreos-9affected: no fix available “Fix deferred”
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-8not affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.21% chance of exploitation in the next 30 days, higher than 10% of all scored CVEs (FIRST EPSS, 2026-11-08).
Affected products
- Linux Linux
Classification
- Technology feeds
References
- git.kernel.org /stable/c/6352e7ead2d8111802a554eeb94886f5a9894bb9
- git.kernel.org /stable/c/7de792b4c48fba02a36a8077032f7d5093c925e5
- git.kernel.org /stable/c/aed8af338a09a64d63b068a803c4ecfc5701dd4c
- git.kernel.org /stable/c/32456a85995579e56c60cc53c357cda75a9d4f7c
- git.kernel.org /stable/c/d3d35dd045a35991bf6fd13de5f293e6dd7bf3b3
- git.kernel.org /stable/c/4e1f23f9c33c156be7e313b40695af5a3a834739
Sources
- CVE List CVE-2026-90184
- NVD CVE-2026-90184
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.