https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 15:15:53 +0000 https://vulnerability.circl.lu/vuln/cve-2024-35794 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dm-raid: really frozen sync_thread during suspend</p> <p>1) commit f52f5c71f3d4 (&#34;md: fix stopping sync thread&#34;) remove MD_RECOVERY_FROZEN from __md_stop_writes() and doesn&#39;t realize that dm-raid relies on __md_stop_writes() to frozen sync_thread indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in md_stop_writes(), and since stop_sync_thread() is only used for dm-raid in this case, also move stop_sync_thread() to md_stop_writes(). 2) The flag MD_RECOVERY_FROZEN doesn&#39;t mean that sync thread is frozen, it only prevent new sync_thread to start, and it can&#39;t stop the running sync thread; In order to frozen sync_thread, after seting the flag, stop_sync_thread() should be used. 3) The flag MD_RECOVERY_FROZEN doesn&#39;t mean that writes are stopped, use it as condition for md_stop_writes() in raid_postsuspend() doesn&#39;t look correct. Consider that reentrant stop_sync_thread() do nothing, always call md_stop_writes() in raid_postsuspend(). 4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime, and if MD_RECOVERY_FROZEN is cleared while the array is suspended, new sync_thread can start unexpected. Fix this by disallow raid_message() to change sync_thread status during suspend.</p> <p>Note that after commit f52f5c71f3d4 (&#34;md: fix stopping sync thread&#34;), the test shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(), and with previous fixes, the test…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dm-raid: really frozen sync_thread during suspend</p> <p>1) commit f52f5c71f3d4 (&#34;md: fix stopping sync thread&#34;) remove MD_RECOVERY_FROZEN from __md_stop_writes() and doesn&#39;t realize that dm-raid relies on __md_stop_writes() to frozen sync_thread indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in md_stop_writes(), and since stop_sync_thread() is only used for dm-raid in this case, also move stop_sync_thread() to md_stop_writes(). 2) The flag MD_RECOVERY_FROZEN doesn&#39;t mean that sync thread is frozen, it only prevent new sync_thread to start, and it can&#39;t stop the running sync thread; In order to frozen sync_thread, after seting the flag, stop_sync_thread() should be used. 3) The flag MD_RECOVERY_FROZEN doesn&#39;t mean that writes are stopped, use it as condition for md_stop_writes() in raid_postsuspend() doesn&#39;t look correct. Consider that reentrant stop_sync_thread() do nothing, always call md_stop_writes() in raid_postsuspend(). 4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime, and if MD_RECOVERY_FROZEN is cleared while the array is suspended, new sync_thread can start unexpected. Fix this by disallow raid_message() to change sync_thread status during suspend.</p> <p>Note that after commit f52f5c71f3d4 (&#34;md: fix stopping sync thread&#34;), the test shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(), and with previous fixes, the test…</p> https://vulnerability.circl.lu/vuln/cve-2024-35794