GHSA-6CWP-GQ4Q-QCCV
Vulnerability from github – Published: 2026-09-17 18:31 – Updated: 2026-09-17 18:31In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix max_qid race between configfs and controller allocation
The function nvmet_subsys_attr_qid_max_store() can race against nvmet_alloc_ctrl() when a subsystem's max_qid limit is modified.
Suppose max_qid is currently 64. If nvmet_alloc_ctrl() executes: ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1); and at this exact point, a userspace process changes max_qid to 128, nvmet_subsys_attr_qid_max_store() will set the new max_qid value. It attempts to delete active controllers to force a reconnect, but the new controller won't be deleted because it hasn't been added to the subsys->ctrls list yet.
nvmet_alloc_ctrl() then proceeds and adds the new controller to the subsys->ctrls list. Later, when nvmet_install_queue() is called, it will see max_qid set to 128, but the memory allocated for sqs is only sized for 64 entries. This results in a KASAN out-of-bounds warning and potential memory corruptions.
Fix this by protecting the queue allocations and list insertion in nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem) to modify the attribute, this safely prevents the configfs writer from modifying max_qid during controller creation.
Copy the max_qid from the subsystem to the controller's structure during the allocation; ctrl->max_qid never changes as long as the controller remains in LIVE state, so this will prevent similar race conditions.
{
"affected": [],
"aliases": [
"CVE-2026-90206"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-17T17:17:15Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix max_qid race between configfs and controller allocation\n\nThe function nvmet_subsys_attr_qid_max_store() can race against\nnvmet_alloc_ctrl() when a subsystem\u0027s max_qid limit is modified.\n\nSuppose max_qid is currently 64. If nvmet_alloc_ctrl() executes:\nctrl-\u003esqs = kzalloc_objs(struct nvmet_sq *, subsys-\u003emax_qid + 1);\nand at this exact point, a userspace process changes max_qid to 128,\nnvmet_subsys_attr_qid_max_store() will set the new max_qid value. It\nattempts to delete active controllers to force a reconnect, but the\nnew controller won\u0027t be deleted because it hasn\u0027t been added to the\nsubsys-\u003ectrls list yet.\n\nnvmet_alloc_ctrl() then proceeds and adds the new controller to the\nsubsys-\u003ectrls list. Later, when nvmet_install_queue() is called, it\nwill see max_qid set to 128, but the memory allocated for sqs is only\nsized for 64 entries. This results in a KASAN out-of-bounds warning\nand potential memory corruptions.\n\nFix this by protecting the queue allocations and list insertion in\nnvmet_alloc_ctrl() with down_read(\u0026nvmet_config_sem). Because\nnvmet_subsys_attr_qid_max_store() acquires down_write(\u0026nvmet_config_sem)\nto modify the attribute, this safely prevents the configfs writer from\nmodifying max_qid during controller creation.\n\nCopy the max_qid from the subsystem to the controller\u0027s structure\nduring the allocation; ctrl-\u003emax_qid never changes as long as the\ncontroller remains in LIVE state, so this will prevent similar race\nconditions.",
"id": "GHSA-6cwp-gq4q-qccv",
"modified": "2026-09-17T18:31:55Z",
"published": "2026-09-17T18:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90206"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2c23fc91789dfd9db746edb3ae9b90d65fabd410"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f1a8846e06388113dfdbb89dee005083fa9afdf9"
}
],
"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.