CVE-2024-26755: Vulnerability in Linux Linux

Severity: mediumType: vulnerabilityCVE-2024-26755

In the Linux kernel, the following vulnerability has been resolved: md: Don't suspend the array for interrupted reshape md_start_sync() will suspend the array if there are spares that can be added or removed from conf, however, if reshape is still in progress, this won't happen at all or data will be corrupted(remove_and_add_spares won't be called from md_choose_sync_action for reshape), hence there is no need to suspend the array if reshape is not done yet. Meanwhile, there is a potential deadlock for raid456: 1) reshape is interrupted; 2) set one of the disk WantReplacement, and add a new disk to the array, however, recovery won't start until the reshape is finished; 3) then issue an IO across reshpae position, this IO will wait for reshape to make progress; 4) continue to reshape, then md_start_sync() found there is a spare disk that can be added to conf, mddev_suspend() is called; Step 4 and step 3 is waiting for each other, deadlock triggered. Noted this problem is found by code review, and it's not reporduced yet. Fix this porblem by don't suspend the array for interrupted reshape, this is safe because conf won't be changed until reshape is done.

AI Analysis

Technical Summary

CVE-2024-26755 addresses a vulnerability in the Linux kernel's md (multiple device) subsystem, which manages RAID arrays. The issue arises during the reshape operation of RAID arrays, specifically RAID levels 4, 5, and 6. The reshape process involves changing the RAID layout or adding/removing disks. The vulnerability is due to improper handling of array suspension when a reshape operation is interrupted. Normally, md_start_sync() suspends the array if spare disks can be added or removed. However, if a reshape is still in progress or interrupted, the suspension does not occur correctly, potentially leading to data corruption or a deadlock. The deadlock scenario occurs when: (1) a reshape is interrupted; (2) a disk is marked for replacement and a new disk is added; (3) I/O operations wait on the reshape to progress; (4) md_start_sync() attempts to suspend the array to add the spare disk, but this conflicts with the waiting I/O, causing a deadlock. This deadlock can halt RAID operations, impacting availability. The fix implemented prevents suspending the array during an interrupted reshape, as configuration changes are not allowed until reshape completion, thus avoiding the deadlock and potential data corruption. The vulnerability has a CVSS v3.1 score of 5.3 (medium severity), reflecting a network attack vector with no privileges or user interaction required, impacting availability only. No known exploits are reported in the wild, and the issue was discovered through code review rather than active exploitation.

Potential Impact

For European organizations relying on Linux servers with RAID456 configurations, this vulnerability could lead to temporary unavailability of critical storage arrays due to deadlocks during interrupted reshape operations. This may disrupt services dependent on these storage systems, affecting business continuity and operational efficiency. While the vulnerability does not compromise confidentiality or integrity directly, the potential for data corruption during interrupted reshape operations poses a risk to data reliability. Organizations with high-availability requirements, such as financial institutions, healthcare providers, and critical infrastructure operators, could experience service interruptions or require emergency maintenance to recover from deadlocks. The lack of known exploits reduces immediate risk, but the medium severity and potential for availability impact warrant timely patching to prevent future incidents.

Mitigation Recommendations

European organizations should promptly apply the Linux kernel updates that include the fix for CVE-2024-26755. Specifically, ensure that all systems running RAID456 configurations are updated to kernel versions containing the patch that prevents array suspension during interrupted reshapes. Additionally, administrators should: 1) Monitor RAID reshape operations closely and avoid interrupting them unless absolutely necessary. 2) Implement robust backup and recovery procedures to mitigate risks of data corruption during reshape processes. 3) Use RAID management tools that provide clear visibility into reshape status and disk replacement operations to prevent conflicting actions. 4) Test kernel updates in staging environments before production deployment to ensure compatibility and stability. 5) Consider scheduling reshape operations during maintenance windows to minimize impact if issues arise. These steps go beyond generic advice by focusing on operational practices specific to RAID management and reshape procedures.