CVE-2026-53123 Overview
CVE-2026-53123 is a Linux kernel vulnerability in the multiple devices (md) RAID456 subsystem. The flaw causes a deadlock between direct I/O operations and the mddev_suspend() path during a frozen reshape. Direct I/O crossing the reshape position sleeps in raid5_make_request() while holding an active_io reference. When userspace freezes the reshape and writes to md/suspend_lo or md/suspend_hi, the suspend path waits indefinitely for in-flight I/O to drain. The fix wakes reshape waiters before suspend so blocked I/O can abort and release its reference.
Critical Impact
A local user with permissions to manage md devices can trigger a kernel deadlock in RAID456 reshape, hanging I/O and storage management operations.
Affected Products
- Linux kernel versions containing the md RAID456 reshape code path prior to the referenced stable commits
- Systems using software RAID 4/5/6 (raid456) via the md driver
- Distributions shipping affected upstream kernels that perform online RAID reshape operations
Discovery Timeline
- 2026-06-24 - CVE-2026-53123 published to NVD
- 2026-06-24 - Last updated in NVD database
Technical Details for CVE-2026-53123
Vulnerability Analysis
The defect is a deadlock [CWE-833] in the Linux md RAID456 reshape logic. During an online reshape, the device contains a moving reshape position separating already-reshaped and not-yet-reshaped regions. Direct I/O that crosses this boundary blocks inside raid5_make_request() on the wait_for_reshape waitqueue while still holding an active_io reference on the md device.
If userspace then freezes the reshape thread through sysfs and writes to md/suspend_lo or md/suspend_hi, the kernel invokes mddev_suspend(). That path kills new active_io references and waits for all in-flight I/O to drain. The previously blocked I/O cannot complete because the reshape thread that would advance the reshape position is already frozen. The suspend caller waits forever for the reference to be released.
The upstream fix mirrors behavior that raid5_prepare_suspend() already provides for dm-raid. It wakes wait_for_reshape on the normal md suspend path when the reshape is interrupted. Blocked I/O can then abort, drop its active_io reference, and allow suspend to finish. The mdadm regression test tests/25raid456-reshape-deadlock reproduces the hang.
Root Cause
The root cause is missing waiter wake-up logic in the md suspend path. mddev_suspend() did not signal the wait_for_reshape queue, so I/O sleeping for reshape progress could not exit when the reshape thread was frozen. This created a circular wait between the suspend caller and the blocked I/O.
Attack Vector
The attack vector is local. A user with privileges to administer md devices, typically root or a process with CAP_SYS_ADMIN, can trigger the deadlock by initiating a RAID456 reshape, issuing direct I/O across the reshape position, freezing the reshape, and writing to the suspend sysfs attributes. The result is a hung task in the storage stack rather than memory corruption or code execution. Remote, unauthenticated exploitation is not described in the advisory.
No verified public exploit code is available. The vulnerability manifests through the documented mdadm reproducer rather than a weaponized payload. Refer to the upstream stable commits for the precise code paths modified.
Detection Methods for CVE-2026-53123
Indicators of Compromise
- Hung task warnings in dmesg referencing raid5_make_request, mddev_suspend, or wait_for_reshape
- Processes stuck in uninterruptible sleep (D state) performing I/O against an md RAID 4/5/6 array undergoing reshape
- mdadm --grow or sysfs writes to md/suspend_lo or md/suspend_hi that never return on a frozen reshape
Detection Strategies
- Monitor kernel logs for INFO: task ... blocked for more than messages with stack traces involving md RAID456 functions
- Inventory hosts running software RAID 4/5/6 and check installed kernel versions against the fixed stable releases referenced in the upstream commits
- Audit administrative activity that toggles sync_action, suspend_lo, or suspend_hi on md arrays during active reshape windows
Monitoring Recommendations
- Alert on sustained D-state processes whose stacks include raid5_make_request or mddev_suspend
- Track storage I/O latency on md RAID456 volumes and flag arrays where I/O stalls coincide with reshape operations
- Centralize kernel log collection so hung task traces from affected hosts can be correlated and triaged
How to Mitigate CVE-2026-53123
Immediate Actions Required
- Apply the upstream stable kernel update containing the fix and reboot affected hosts during a maintenance window
- Avoid writing to md/suspend_lo or md/suspend_hi while a RAID456 reshape is frozen on unpatched kernels
- Restrict administrative access to md sysfs controls and mdadm to trusted operators only
Patch Information
The issue is resolved by the upstream commits that wake wait_for_reshape from the md suspend path when reshape is interrupted. See Kernel Git Commit 8ae3e14, Kernel Git Commit 8b6a724, Kernel Git Commit cf86bb5, and Kernel Git Commit ff6b934. Consume the fix through your distribution's stable kernel update channel.
Workarounds
- Schedule RAID456 reshape operations during quiet windows with no concurrent direct I/O across the reshape position
- Do not freeze the reshape thread while issuing suspend writes; allow reshape to complete or resume before suspending the array
- If a hang occurs, avoid further sysfs writes that may compound the deadlock and plan a controlled reboot to recover the array
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
