Linux · Linux Kernel · CVE-2024-39476
**Name of the Vulnerable Software and Affected Versions**
Linux kernel versions prior to 6.6.37
**Description**
The issue is related to a deadlock in the `raid5d()` function, which can cause the system to hang. This is due to a weird dependence in the current implementation of `raid5d()`:
1. `md check recovery()` from `raid5d()` must hold `reconfig mutex` to clear `MD SB CHANGE PENDING`;
2. `raid5d()` handles IO in a deadloop, until all IO are issued;
3. IO from `raid5d()` must wait for `MD SB CHANGE PENDING` to be cleared.
This behavior was introduced before version 2.6, and as a consequence, if another context holds `reconfig mutex` and `md check recovery()` can't update `super block`, then `raid5d()` will waste one CPU at 100% by the deadloop, until `reconfig mutex` is released.
**Recommendations**
To resolve the issue, update the Linux kernel to version 6.6.37 or later.
As a temporary workaround, consider disabling the `raid5d()` function until a patch is available.
Restrict access to the vulnerable module to minimize the risk of exploitation.
Avoid using the `md check recovery()` function in the affected API endpoint until the issue is resolved.
Apply the fix by skipping issue IO if `MD SB CHANGE PENDING` is still set after `md check recovery()`, allowing the daemon thread to be woken up when `reconfig mutex` is released.