CVE-2024-26757

What it actually does

Race condition in md_check_recovery() allows a read-only md array to retain MD_RECOVERY_RUNNING state after dm-raid manipulates mddev->ro, preventing sync thread unregistration and causing permanent hang on array stop.

Why it matters to the business

Systems using dm-raid or md/raid may experience unrecoverable hangs during array shutdown or reconfiguration, leading to extended downtime, data unavailability, and forced reboots on affected Linux kernels.

How an attack unfolds

An attacker with local access to trigger array state transitions (read-only to read-write via dm-raid superblock updates followed by immediate return to read-only) can race md_check_recovery() and stop_sync_thread to leave the recovery flag set, blocking daemon thread progress and hanging the system.

How to fix it

Upgrade to Linux kernel commits 2ea169c5a0b1134d573d07fc27a16f327ad0e7d3 or 45acb4efbcaa57a20ac5127dc976538671fce018 (or later stable releases containing the fix) and ensure dm-raid stops sync threads before altering array read-only state.

How to confirm the fix worked

Confirm kernel version includes the referenced commit; reproduce integrity-caching.sh test scenario and verify md_check_recovery() now respects read-only status without hanging on array stop.

Typical attack path

1. Obtain local access or control over dm-raid device configuration
2. Trigger rs_update_sbs to temporarily set mddev->ro=0 then restore read-only
3. Concurrently register sync thread while array is writable
4. Issue array stop or raid_dtr to invoke stop_sync_thread
5. Observe deadlock where MD_RECOVERY_RUNNING cannot be cleared

How to detect it

Review kernel logs for hung task warnings involving md_check_recovery, md_do_sync, or raid_dtr; inspect dmesg and syslog for MD_RECOVERY_RUNNING flags that persist after array stop attempts.

• md_check_recovery: ignoring read-only
• wait_event.*MD_RECOVERY_RUNNING
• md_stop.*stop_sync_thread
• rs_update_sbs.*mddev->ro

What your security team should do

• Prioritize kernel upgrades on systems using md/raid or dm-raid within 30 days due to potential stability impact
• Audit all md arrays for read-only configurations and dm-raid usage
• Monitor for kernel oops or hung task reports during array teardown
• Test array stop and reconfiguration procedures in staging environments after patching