PT-2024-5439 · Linux+8 · Linux Kernel+8
Dan Moulding
+1
·
Published
2024-04-08
·
Updated
2025-09-29
·
CVE-2024-39476
CVSS v3.1
5.5
Medium
| Vector | AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H |
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():md check recovery()fromraid5d()must holdreconfig mutexto clearMD SB CHANGE PENDING;raid5d()handles IO in a deadloop, until all IO are issued;- IO from
raid5d()must wait forMD SB CHANGE PENDINGto be cleared. This behavior was introduced before version 2.6, and as a consequence, if another context holdsreconfig mutexandmd check recovery()can't updatesuper block, thenraid5d()will waste one CPU at 100% by the deadloop, untilreconfig mutexis 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.Exploit
Fix
Improper Locking
Found an issue in the description? Have something to add? Feel free to write us 👾
Weakness Enumeration
Related Identifiers
Affected Products
Alt Linux
Almalinux
Astra Linux
Centos
Linux Kernel
Red Hat
Red Os
Rocky Linux
Suse