CVE-2024-26962 in Linux
Summary
by MITRE • 05/01/2024
In the Linux kernel, the following vulnerability has been resolved:
dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape
For raid456, if reshape is still in progress, then IO across reshape position will wait for reshape to make progress. However, for dm-raid, in following cases reshape will never make progress hence IO will hang:
1) the array is read-only; 2) MD_RECOVERY_WAIT is set; 3) MD_RECOVERY_FROZEN is set;
After commit c467e97f079f ("md/raid6: use valid sector values to determine if an I/O should wait on the reshape") fix the problem that IO across reshape position doesn't wait for reshape, the dm-raid test shell/lvconvert-raid-reshape.sh start to hang:
[root@fedora ~]# cat /proc/979/stack
[] wait_woken+0x7d/0x90
[] raid5_make_request+0x929/0x1d70 [raid456]
[] md_handle_request+0xc2/0x3b0 [md_mod]
[] raid_map+0x2c/0x50 [dm_raid]
[] __map_bio+0x251/0x380 [dm_mod]
[] dm_submit_bio+0x1f0/0x760 [dm_mod]
[] __submit_bio+0xc2/0x1c0
[] submit_bio_noacct_nocheck+0x17f/0x450
[] submit_bio_noacct+0x2bc/0x780
[] submit_bio+0x70/0xc0
[] mpage_readahead+0x169/0x1f0
[] blkdev_readahead+0x18/0x30
[] read_pages+0x7c/0x3b0
[] page_cache_ra_unbounded+0x1ab/0x280
[] force_page_cache_ra+0x9e/0x130
[] page_cache_sync_ra+0x3b/0x110
[] filemap_get_pages+0x143/0xa30
[] filemap_read+0xdc/0x4b0
[] blkdev_read_iter+0x75/0x200
[] vfs_read+0x272/0x460
[] ksys_read+0x7a/0x170
[] __x64_sys_read+0x1c/0x30
[] do_syscall_64+0xc6/0x230
[] entry_SYSCALL_64_after_hwframe+0x6c/0x74
This is because reshape can't make progress.
For md/raid, the problem doesn't exist because register new sync_thread doesn't rely on the IO to be done any more:
1) If array is read-only, it can switch to read-write by ioctl/sysfs; 2) md/raid never set MD_RECOVERY_WAIT; 3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold 'reconfig_mutex', hence it can be cleared and reshape can continue by sysfs api 'sync_action'.
However, I'm not sure yet how to avoid the problem in dm-raid yet. This patch on the one hand make sure raid_message() can't change sync_thread() through raid_message() after presuspend(), on the other hand detect the above 3 cases before wait for IO do be done in dm_suspend(), and let dm-raid requeue those IO.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 01/26/2026
The vulnerability described in CVE-2024-26962 affects the Linux kernel's device mapper raid456 implementation, specifically exposing a deadlock condition that occurs during concurrent input/output operations while a reshape operation is in progress. This issue manifests within the dm-raid456 subsystem where I/O requests that cross the reshape position become indefinitely blocked, creating a system-wide hang condition. The root cause stems from the interaction between the device mapper's raid456 layer and the underlying md/raid456 subsystem, where certain reshape states prevent progress even though I/O operations are waiting for the reshape to complete.
The technical flaw occurs when reshape operations encounter specific conditions that prevent them from making forward progress, namely when the array is read-only, when MD_RECOVERY_WAIT is set, or when MD_RECOVERY_FROZEN is active. These conditions create a circular dependency where I/O operations wait for reshape progress that cannot occur, while the reshape operation itself cannot proceed due to the blocking I/O requests. The vulnerability was introduced following a previous fix commit c467e97f079f that altered how I/O operations determine whether they should wait for reshape completion, inadvertently exposing this deadlock scenario in dm-raid implementations.
The operational impact of this vulnerability is severe, as it can cause complete system hangs during concurrent I/O and reshape operations, particularly affecting storage systems that rely on device mapper RAID functionality. The stack trace reveals the blocking mechanism through multiple kernel subsystems including raid5_make_request, md_handle_request, raid_map, and dm_submit_bio, demonstrating how the deadlock propagates through the storage I/O stack. This affects enterprise storage environments where RAID reshape operations are common during system maintenance or capacity expansion activities.
The mitigation approach requires careful handling of reshape state conditions before allowing I/O operations to proceed, ensuring that dm-raid can detect the problematic cases and requeue I/O operations rather than allowing them to block indefinitely. This solution addresses the fundamental mismatch between how md/raid and dm-raid handle reshape state management, where the latter lacks the flexibility to transition out of problematic states that would normally be resolved through direct md/raid interfaces. The fix implements a presuspend mechanism that prevents synchronization thread modifications during critical operations while detecting the three problematic reshape states that cause the deadlock, allowing the system to maintain operational continuity through proper I/O queuing mechanisms.
This vulnerability aligns with CWE-367, which addresses time-of-check to time-of-use (TOCTOU) race conditions, and relates to ATT&CK technique T1485, which covers data destruction through system resource manipulation. The issue demonstrates how complex kernel subsystem interactions can create unexpected deadlock scenarios that compromise system availability, particularly in storage virtualization environments where device mapper RAID is extensively used. The vulnerability represents a significant risk to enterprise systems that perform concurrent I/O operations during RAID reshape activities, potentially leading to extended downtime and service disruption during routine maintenance operations.