CVE-2024-35794

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-raid: really frozen sync_thread during suspend<br /> <br /> 1) commit f52f5c71f3d4 ("md: fix stopping sync thread") remove<br /> MD_RECOVERY_FROZEN from __md_stop_writes() and doesn&amp;#39;t realize that<br /> dm-raid relies on __md_stop_writes() to frozen sync_thread<br /> indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in<br /> md_stop_writes(), and since stop_sync_thread() is only used for<br /> dm-raid in this case, also move stop_sync_thread() to<br /> md_stop_writes().<br /> 2) The flag MD_RECOVERY_FROZEN doesn&amp;#39;t mean that sync thread is frozen,<br /> it only prevent new sync_thread to start, and it can&amp;#39;t stop the<br /> running sync thread; In order to frozen sync_thread, after seting the<br /> flag, stop_sync_thread() should be used.<br /> 3) The flag MD_RECOVERY_FROZEN doesn&amp;#39;t mean that writes are stopped, use<br /> it as condition for md_stop_writes() in raid_postsuspend() doesn&amp;#39;t<br /> look correct. Consider that reentrant stop_sync_thread() do nothing,<br /> always call md_stop_writes() in raid_postsuspend().<br /> 4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime,<br /> and if MD_RECOVERY_FROZEN is cleared while the array is suspended,<br /> new sync_thread can start unexpected. Fix this by disallow<br /> raid_message() to change sync_thread status during suspend.<br /> <br /> Note that after commit f52f5c71f3d4 ("md: fix stopping sync thread"), the<br /> test shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(),<br /> and with previous fixes, the test won&amp;#39;t hang there anymore, however, the<br /> test will still fail and complain that ext4 is corrupted. And with this<br /> patch, the test won&amp;#39;t hang due to stop_sync_thread() or fail due to ext4<br /> is corrupted anymore. However, there is still a deadlock related to<br /> dm-raid456 that will be fixed in following patches.