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...

Classification

CVE ID: CVE-2024-26757

Affected Products

Vendor: Linux

Product: Linux

Exploit Prediction Scoring System (EPSS)

EPSS Score: 0.04% (probability of being exploited)

EPSS Percentile: 11.48% (scored less or equal to compared to others)

EPSS Date: 2025-02-04 (when was this score calculated)

References

https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3
https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b

Timeline