GHSA-VMH6-CGXH-HRG9
Vulnerability from github – Published: 2026-09-17 18:31 – Updated: 2026-09-17 18:31In 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().
{
"affected": [],
"aliases": [
"CVE-2026-90184"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-17T17:17:12Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnull_blk: serialize configfs attribute updates with device setup\n\nThe attribute store methods generated with NULLB_DEVICE_ATTR() refuse to\nchange the configuration of a live device by testing\nNULLB_DEV_FL_CONFIGURED, but that flag is only set by\nnullb_device_power_store() after null_add_dev() has returned, and the\nstore methods take no lock at all. configfs only serializes writes to\nthe same open file (buffer-\u003emutex), so a write to any attribute can run\nconcurrently with null_add_dev() and change the device configuration\nwhile it is being used.\n\nnull_add_dev() reads the configuration several times, e.g. dev-\u003ezoned is\nread once to set up the queue limits and once to initialize the zone\nresources:\n\n CPU0: echo 1 \u003e nullb0/power CPU1: echo 1 \u003e nullb0/zoned\n nullb_device_power_store()\n mutex_lock(\u0026lock)\n null_add_dev()\n if (dev-\u003ezoned) -\u003e false\n /* no BLK_FEAT_ZONED */ nullb_device_zoned_store()\n test_bit(FL_CONFIGURED) -\u003e 0\n dev-\u003ezoned = true\n blk_mq_alloc_disk()\n /* queue is not zoned */\n if (nullb-\u003edev-\u003ezoned) -\u003e true\n null_register_zoned_dev()\n blk_revalidate_disk_zones()\n\nblk_revalidate_disk_zones() is then called for a queue that does not\nhave BLK_FEAT_ZONED set, which triggers its WARN_ON_ONCE() and fails the\ndevice setup with -EIO:\n\n WARNING: CPU: 2 PID: 322 at block/blk-zoned.c:2357 blk_revalidate_disk_zones+0x4c/0x560\n\nClearing dev-\u003ezoned in the same window is worse: the queue is created\nwith BLK_FEAT_ZONED but the zone resources are never initialized, so\nadd_disk() succeeds for a zoned disk that has no zones. And a store that\nlands after the last dev-\u003ezoned test leaves dev-\u003ezoned set while\ndev-\u003ezones is still NULL, which null_process_zoned_cmd() dereferences on\nthe first write.\n\nFix this by taking the global lock, which nullb_device_power_store()\nalready holds across null_add_dev() and null_del_dev(), around both the\nNULLB_DEV_FL_CONFIGURED test and the update of the device configuration.\nThe submit_queues and poll_queues apply callbacks are now called with\nthat lock held, so remove the locking they did themselves.\n\nSince the store methods can run as soon as configfs_register_subsystem()\nreturns, that is, before null_init() gets to mutex_init(\u0026lock), also\ninitialize the lock statically with DEFINE_MUTEX().",
"id": "GHSA-vmh6-cgxh-hrg9",
"modified": "2026-09-17T18:31:54Z",
"published": "2026-09-17T18:31:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90184"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32456a85995579e56c60cc53c357cda75a9d4f7c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e1f23f9c33c156be7e313b40695af5a3a834739"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6352e7ead2d8111802a554eeb94886f5a9894bb9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7de792b4c48fba02a36a8077032f7d5093c925e5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aed8af338a09a64d63b068a803c4ecfc5701dd4c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d3d35dd045a35991bf6fd13de5f293e6dd7bf3b3"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.