FKIE_CVE-2026-90400
Vulnerability from fkie_nvd - Published: 2026-09-17 17:17 - Updated: 2026-09-17 17:17
Severity
Summary
In 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.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/md/md.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "c3777d16bc3335c0ac4bdad0551c80d38c5d94cc",
"status": "affected",
"version": "bc08041b32abe6c9824f78735bac22018eabfc06",
"versionType": "git"
},
{
"lessThan": "e5ac7ab78467b064f1da8b0f3042a63595fafcfd",
"status": "affected",
"version": "bc08041b32abe6c9824f78735bac22018eabfc06",
"versionType": "git"
},
{
"lessThan": "81b39df5d701976cf20e52f33106c1fc1603b4cb",
"status": "affected",
"version": "bc08041b32abe6c9824f78735bac22018eabfc06",
"versionType": "git"
},
{
"lessThan": "c7d34d17ea43ebc86b45d439ebb435e11ca44bca",
"status": "affected",
"version": "bc08041b32abe6c9824f78735bac22018eabfc06",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/md/md.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.7"
},
{
"lessThan": "6.7",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.110",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.52",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3-rc1",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "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": "CVE-2026-90400",
"lastModified": "2026-09-17T17:17:39.753",
"metrics": {},
"published": "2026-09-17T17:17:39.753",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/81b39df5d701976cf20e52f33106c1fc1603b4cb"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c3777d16bc3335c0ac4bdad0551c80d38c5d94cc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c7d34d17ea43ebc86b45d439ebb435e11ca44bca"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e5ac7ab78467b064f1da8b0f3042a63595fafcfd"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
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.
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
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.
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.
Loading…
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.
Loading…