CVE-2024-26758

What it actually does

Race condition in md_check_recovery() skips unregistration of sync_thread for suspended MD arrays, leaving MD_RECOVERY_RUNNING set and preventing clean stop of the array.

Why it matters to the business

Storage management operations on Linux RAID arrays can hang indefinitely, leading to reduced system availability and potential data access disruptions in environments using md or dm-raid.

How an attack unfolds

An attacker with local access triggers array suspend followed by stop, causing the sync thread to complete without clearing recovery flags; the daemon thread then blocks indefinitely due to the suspended check bypass.

How to fix it

Update the Linux kernel to a version containing commit a55f0d6179a19c6b982e2dc344d58c98647a3be0 or equivalent fixed commit d1950a5021f4e19d92f347614be0d85ce991510d; rebuild and reboot affected systems.

How to confirm the fix worked

Verify kernel source contains the fix commit, confirm md_check_recovery no longer returns early on suspended arrays, and re-execute integrity-caching test scenarios without observing hangs.

Typical attack path

1. Obtain local access to trigger md device operations
2. Suspend the MD array via raid_postsuspend or equivalent
3. Stop the array to invoke stop_sync_thread and wait on recovery flag
4. Allow sync thread to set MD_RECOVERY_DONE and wake the daemon
5. Observe hang when md_check_recovery returns early on suspended state

How to detect it

Inspect kernel logs and dmesg for MD recovery thread hangs, repeated wait_event calls on MD_RECOVERY_RUNNING, and failure to clear recovery bits after array stop; correlate with raid_dtr and md_stop call stacks.

What your security team should do

• Apply the kernel fix immediately on all systems using md or dm-raid
• Prioritize patching for production storage servers given the hang risk
• Monitor kernel logs for MD recovery thread warnings during array stop operations
• Test RAID suspend/stop sequences in staging before production rollout