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.

References

• https://nvd.nist.gov/vuln/detail/CVE-2024-26757
• https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3
• https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b