CVE-2024-39476

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING<br /> <br /> Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with<br /> small possibility, the root cause is exactly the same as commit<br /> bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")<br /> <br /> However, Dan reported another hang after that, and junxiao investigated<br /> the problem and found out that this is caused by plugged bio can&amp;#39;t issue<br /> from raid5d().<br /> <br /> Current implementation in raid5d() has a weird dependence:<br /> <br /> 1) md_check_recovery() from raid5d() must hold &amp;#39;reconfig_mutex&amp;#39; to clear<br /> MD_SB_CHANGE_PENDING;<br /> 2) raid5d() handles IO in a deadloop, until all IO are issued;<br /> 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;<br /> <br /> This behaviour is introduce before v2.6, and for consequence, if other<br /> context hold &amp;#39;reconfig_mutex&amp;#39;, and md_check_recovery() can&amp;#39;t update<br /> super_block, then raid5d() will waste one cpu 100% by the deadloop, until<br /> &amp;#39;reconfig_mutex&amp;#39; is released.<br /> <br /> Refer to the implementation from raid1 and raid10, fix this problem by<br /> skipping issue IO if MD_SB_CHANGE_PENDING is still set after<br /> md_check_recovery(), daemon thread will be woken up when &amp;#39;reconfig_mutex&amp;#39;<br /> is released. Meanwhile, the hang problem will be fixed as well.