GHSA-VWGQ-HPCR-5X9R
Vulnerability from github – Published: 2026-09-17 18:32 – Updated: 2026-09-17 18:32In the Linux kernel, the following vulnerability has been resolved:
md: recheck spare changes before starting sync
remove_spares() and remove_and_add_spares() modify the array's rdev configuration. These operations are only safe after the array has been suspended.
md_start_sync() checks whether spare configuration changes are needed before taking reconfig_mutex. However, the rdev state can change before the mutex is acquired, so the initial check can become stale. In that case, md_choose_sync_action() may remove or replace rdevs while normal I/O is still accessing them.
The race can occur as follows:
raid10d Worker Normal IO __ ___ ____
raid10_write_request()
wait_blocked_dev()
set Blocked set Faulty Skip Faulty rdev rrdev->nr_pending++ .repl_bio = bio removeable_rdev = false . array not suspended . lock mddev goto err_handle lock mddev (wait) . update sb . clear Blocked . . unlock mddev . lock mddev (acquires) remove_spares() removeable_rdev = true
raid10_remove_disk()
rdev = replacement
replacement = NULL
rdev_dec_pending(NULL)
unlock mddev (NULL)->nr_pending--
In this case, rdev_dec_pending() is called with a NULL pointer, resulting in a NULL pointer dereference when attempting to decrement nr_pending.
Fix this by suspending the array when spare configuration changes are needed, including for non-read-write arrays, and checking again after taking reconfig_mutex. If the array was not already suspended and a change is now needed, release the mutex, suspend the array, and reacquire the mutex before continuing.
{
"affected": [],
"aliases": [
"CVE-2026-90400"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-17T17:17:39Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: recheck spare changes before starting sync\n\nremove_spares() and remove_and_add_spares() modify the array\u0027s rdev\nconfiguration. These operations are only safe after the array has been\nsuspended.\n\nmd_start_sync() checks whether spare configuration changes are needed\nbefore taking reconfig_mutex. However, the rdev state can change before\nthe mutex is acquired, so the initial check can become stale. In that\ncase, md_choose_sync_action() may remove or replace rdevs while normal\nI/O is still accessing them.\n\nThe race can occur as follows:\n\nraid10d Worker Normal IO\n____________ _______________________ ______________________\n\n raid10_write_request()\n wait_blocked_dev()\nset Blocked\nset Faulty\n Skip Faulty rdev\n rrdev-\u003enr_pending++\n .repl_bio = bio\n removeable_rdev = false .\n array not suspended .\nlock mddev goto err_handle\n lock mddev (wait)\n .\nupdate sb .\nclear Blocked .\n .\nunlock mddev .\n lock mddev (acquires)\n remove_spares()\n removeable_rdev = true\n\n raid10_remove_disk()\n rdev = replacement\n replacement = NULL\n rdev_dec_pending(NULL)\n unlock mddev (NULL)-\u003enr_pending--\n\nIn this case, rdev_dec_pending() is called with a NULL pointer,\nresulting in a NULL pointer dereference when attempting to decrement\nnr_pending.\n\nFix this by suspending the array when spare configuration changes are\nneeded, including for non-read-write arrays, and checking again after\ntaking reconfig_mutex. If the array was not already suspended and a\nchange is now needed, release the mutex, suspend the array, and\nreacquire the mutex before continuing.",
"id": "GHSA-vwgq-hpcr-5x9r",
"modified": "2026-09-17T18:32:04Z",
"published": "2026-09-17T18:32:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90400"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/81b39df5d701976cf20e52f33106c1fc1603b4cb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c3777d16bc3335c0ac4bdad0551c80d38c5d94cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7d34d17ea43ebc86b45d439ebb435e11ca44bca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e5ac7ab78467b064f1da8b0f3042a63595fafcfd"
}
],
"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.