CVE Published: 03/04/2024 |
CVE Updated: 06/11/2024 |
CVE Year: 2024 Source: Linux |
Vendor: Linux |
Product: Linux Status : PUBLISHED
CVE-2024-26757 Description
In the Linux kernel, the following vulnerability has been resolved:
md: Don\'t ignore read-only array in md_check_recovery()
Usually if the array is not read-write, md_check_recovery() won\'t
register new sync_thread in the first place. And if the array is
read-write and sync_thread is registered, md_set_readonly() will
unregister sync_thread before setting the array read-only. md/raid
follow this behavior hence there is no problem.
After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following
hang can be triggered by test shell/integrity-caching.sh:
1) array is read-only. dm-raid update super block:
rs_update_sbs
ro = mddev->ro
mddev->ro = 0
-> set array read-write
md_update_sb
2) register new sync thread concurrently.
3) dm-raid set array back to read-only:
rs_update_sbs
mddev->ro = ro
4) stop the array:
raid_dtr
md_stop
stop_sync_thread
set_bit(MD_RECOVERY_INTR, &mddev->recovery);
md_wakeup_thread_directly(mddev->sync_thread);
wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))
5) sync thread done:
md_do_sync
set_bit(MD_RECOVERY_DONE, &mddev->recovery);
md_wakeup_thread(mddev->thread);
6) daemon thread can\'t unregister sync thread:
md_check_recovery
if (!md_is_rdwr(mddev) &&
!test_bit(MD_RECOVERY_NEEDED, &mddev->recovery))
return;
-> -> MD_RECOVERY_RUNNING can\'t be cleared, hence step 4 hang;
The root cause is that dm-raid manipulate \'mddev->ro\' by itself,
however, dm-raid really should stop sync thread before setting the
array read-only. Unfortunately, I need to read more code before I
can refacter the handler of \'mddev->ro\' in dm-raid, hence let\'s fix
the problem the easy way for now to prevent dm-raid regression.