CVE-2026-90400: md: recheck spare changes before starting sync
In the Linux kernel, the following vulnerability has been resolved:
md: recheck spare changes before starting sync
removespares() and removeandaddspares() modify the array's rdev configuration. These operations are only safe after the array has been suspended.
mdstartsync() checks whether spare configuration changes are needed before taking reconfigmutex. However, the rdev state can change before the mutex is acquired, so the initial check can become stale. In that case, mdchoosesyncaction() may remove or replace rdevs while normal I/O is still accessing them.
The race can occur as follows:
raid10d Worker Normal IO
raid10writerequest() waitblockeddev() set Blocked set Faulty Skip Faulty rdev rrdev->nrpending++ .replbio = bio removeablerdev = false . array not suspended . lock mddev goto errhandle lock mddev (wait) . update sb . clear Blocked . . unlock mddev . lock mddev (acquires) removespares() removeablerdev = true
raid10removedisk() rdev = replacement replacement = NULL rdevdecpending(NULL) unlock mddev (NULL)->nrpending--
In this case, rdevdecpending() is called with a NULL pointer, resulting in a NULL pointer dereference when attempting to decrement nrpending.
Fix this by suspending the array when spare configuration changes are needed, including for non-read-write arrays, and checking again after taking reconfigmutex. 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.
Event History
Frequently Asked Questions
Which systems are exposed to this race condition?
Systems using the Linux kernel MD subsystem with RAID10 arrays are exposed when spare or replacement device configuration can change while a sync is being started and normal I/O is in progress.
What conditions are required to trigger the issue?
The race requires concurrent RAID10 activity: normal I/O must be using an rdev while spare removal or replacement processing changes the rdev configuration during sync startup. The affected sequence involves a replacement device becoming NULL before pending I/O accounting completes.
What is the likely impact if the race occurs?
The described outcome is a NULL pointer dereference in rdev_dec_pending(), caused by calling it with a NULL rdev pointer. This can lead to a kernel fault while the array is processing I/O and device replacement activity.
Is a normal, idle RAID10 array affected?
The provided information describes a timing-dependent race involving sync startup, spare or replacement changes, and concurrent normal I/O. It does not indicate that an idle array without these concurrent operations will trigger the issue.