CVE-2024-26962

What it actually does

Deadlock in dm-raid456 when concurrent IO spans the reshape position while reshape cannot advance because the array is read-only, MD_RECOVERY_WAIT is set, or MD_RECOVERY_FROZEN is set; the wait in raid5_make_request never completes.

Why it matters to the business

Linux systems using device-mapper RAID may experience indefinite hangs on read or write operations during reshape, causing application outages and requiring reboots; the issue affects stable kernels prior to the listed fix commit and has been public for over two years with no active exploitation reported.

How an attack unfolds

An attacker with local access or the ability to trigger reshape (via array configuration changes) can arrange one of the three blocking conditions, then issue IO that crosses the reshape boundary; the resulting hang occurs without any remote code execution path and no named threat actors are known to weaponize it.

How to fix it

Upgrade the Linux kernel to a version containing commit 5943a34bf6bab5801e08a55f63e1b8d5bc90dae1 or later; rebuild and reboot with the patched kernel; for dm-raid deployments, also verify that reshape can be resumed after any suspend or flag-clearing operations.

How to confirm the fix worked

Confirm the running kernel contains commit 5943a34bf6bab5801e08a55f63e1b8d5bc90dae1; reproduce the original lvconvert-raid-reshape test scenario and verify IO completes without deadlock; inspect /proc/<pid>/stack for absence of the wait_woken + raid5_make_request pattern under the three blocking conditions.

Typical attack path

1. Configure or convert a dm-raid array that begins a reshape operation
2. Set the array read-only or ensure MD_RECOVERY_WAIT/FROZEN flags are present
3. Submit read or write requests that cross the current reshape position
4. Observe the process stack waiting indefinitely inside raid5_make_request

How to detect it

Search kernel logs and process stacks for threads blocked inside raid5_make_request after a reshape start; correlate with dm-raid array state showing read-only mode or recovery flags; review audit or system logs for reshape initiation followed by stalled I/O submissions.

• raid5_make_request+0x929/0x1d70 [raid456]
• wait_woken+0x7d/0x90
• MD_RECOVERY_WAIT
• MD_RECOVERY_FROZEN
• lvconvert-raid-reshape.sh

What your security team should do

• Apply the fixed kernel commit immediately on all systems using dm-raid456
• Schedule kernel updates through normal patch windows given the low EPSS and absence from KEV
• Monitor for hung blkdev_readahead or raid5_make_request processes during any RAID reshape activity
• Document fallback procedures (reboot or array re-assembly) for environments that cannot patch promptly