CVE-2024-26962: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2024-26962

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 [<0>] wait_woken+0x7d/0x90 [<0>] raid5_make_request+0x929/0x1d70 [raid456] [<0>] md_handle_request+0xc2/0x3b0 [md_mod] [<0>] raid_map+0x2c/0x50 [dm_raid] [<0>] __map_bio+0x251/0x380 [dm_mod] [<0>] dm_submit_bio+0x1f0/0x760 [dm_mod] [<0>] __submit_bio+0xc2/0x1c0 [<0>] submit_bio_noacct_nocheck+0x17f/0x450 [<0>] submit_bio_noacct+0x2bc/0x780 [<0>] submit_bio+0x70/0xc0 [<0>] mpage_readahead+0x169/0x1f0 [<0>] blkdev_readahead+0x18/0x30 [<0>] read_pages+0x7c/0x3b0 [<0>] page_cache_ra_unbounded+0x1ab/0x280 [<0>] force_page_cache_ra+0x9e/0x130 [<0>] page_cache_sync_ra+0x3b/0x110 [<0>] filemap_get_pages+0x143/0xa30 [<0>] filemap_read+0xdc/0x4b0 [<0>] blkdev_read_iter+0x75/0x200 [<0>] vfs_read+0x272/0x460 [<0>] ksys_read+0x7a/0x170 [<0>] __x64_sys_read+0x1c/0x30 [<0>] do_syscall_64+0xc6/0x230 [<0>] 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.

AI Analysis

Technical Summary

CVE-2024-26962 is a vulnerability identified in the Linux kernel's device-mapper RAID456 (dm-raid456) implementation, specifically related to the handling of reshape operations during concurrent I/O. RAID456 is a RAID level combining RAID4, RAID5, and RAID6 features, implemented in the Linux kernel for data redundancy and performance. The vulnerability arises when a reshape operation (which changes the RAID layout or size) is in progress and I/O requests cross the reshape boundary. Normally, such I/O should wait for the reshape to make progress to maintain data integrity and avoid deadlocks. However, in dm-raid456, under certain conditions, the reshape process can stall indefinitely, causing I/O operations to hang and resulting in a deadlock. The three key conditions causing this deadlock are: (1) the RAID array is in a read-only state; (2) the MD_RECOVERY_WAIT flag is set; and (3) the MD_RECOVERY_FROZEN flag is set. These conditions prevent the reshape from progressing, and the I/O waits indefinitely, leading to system hangs or degraded performance. The issue does not affect the traditional md/raid implementation because it handles recovery and reshape differently, avoiding this deadlock scenario. The patch attempts to mitigate the problem by preventing changes to the sync_thread after presuspend and detecting the problematic conditions before waiting for I/O completion, allowing dm-raid to requeue I/O requests instead of hanging. This vulnerability can cause significant disruption in systems relying on dm-raid456 arrays undergoing reshape operations, particularly if the arrays are read-only or in recovery wait/frozen states. No known exploits are reported in the wild yet, and no CVSS score has been assigned at the time of publication.

Potential Impact

For European organizations, especially those operating data centers, cloud infrastructure, or enterprise storage relying on Linux servers with dm-raid456 configurations, this vulnerability poses a risk of system hangs and degraded availability during RAID reshape operations. The deadlock can cause critical storage volumes to become unresponsive, potentially leading to application downtime, data access delays, and operational disruptions. Organizations with read-only RAID arrays or those performing maintenance involving recovery or reshape operations are particularly vulnerable. This can affect sectors such as finance, healthcare, telecommunications, and government services where Linux-based storage reliability is crucial. While the vulnerability does not directly expose data confidentiality or integrity to attackers, the availability impact can be severe, especially in high-availability environments. The lack of known exploits reduces immediate risk, but the complexity of the issue means that unnoticed hangs could lead to cascading failures or require manual intervention, increasing operational costs and risk of data loss if recovery is mishandled.

Mitigation Recommendations

1. Apply the official Linux kernel patches addressing CVE-2024-26962 as soon as they become available to ensure the deadlock condition is resolved. 2. Avoid performing reshape operations on dm-raid456 arrays that are in read-only mode or have MD_RECOVERY_WAIT or MD_RECOVERY_FROZEN flags set until patches are applied. 3. Implement monitoring and alerting for RAID reshape progress and I/O hang conditions to detect early signs of deadlocks. 4. Where possible, schedule reshape operations during maintenance windows with minimal I/O load to reduce risk of hangs. 5. Consider migrating critical RAID arrays from dm-raid456 to md/raid implementations temporarily if reshape operations are necessary and patching is delayed, as md/raid is not affected by this issue. 6. Educate system administrators on the conditions that trigger the deadlock and provide operational guidelines to avoid triggering the problematic states. 7. Regularly review RAID array health and recovery flags to ensure no unexpected states persist that could contribute to deadlocks. 8. Maintain up-to-date backups and disaster recovery plans to mitigate impact of potential storage unavailability.