CVE-2026-53123

What it actually does

This flaw is a Linux kernel md RAID456 denial-of-service condition involving reshape and suspend coordination. During RAID5/RAID6 reshape, direct I/O crossing the reshape position can block in raid5_make_request() while holding an active_io reference. If reshape is then frozen and md suspend boundaries are written through the md sysfs interface, mddev_suspend() waits for active I/O to drain, but the blocked I/O cannot complete because reshape progress is stopped. The result is a kernel-level deadlock affecting the md RAID device, typically presenting as hung I/O, blocked processes, and potentially an unresponsive storage stack until recovery or reboot.

Why it matters to the business

Systems using Linux md RAID5 or RAID6 arrays undergoing reshape may experience storage hangs or service outages if the vulnerable condition is triggered. The most likely consequence is operational downtime for workloads depending on the affected array, delayed maintenance, failed storage automation, or the need for disruptive recovery actions such as restarting services or rebooting. Public exploitation maturity is currently reported as none, EPSS is low, and it is not listed in CISA KEV, so broad internet exploitation is not expected; however, the impact can be significant for organizations that rely on md RAID456 during reshape, expansion, migration, or maintenance operations.

How an attack unfolds

An attacker or local actor with sufficient privileges to manipulate md RAID state would need access to a system using an affected Linux kernel with an md RAID5 or RAID6 array undergoing reshape. They would generate direct I/O that crosses the active reshape position, causing the I/O path to wait for reshape progress while still holding an active I/O reference. The actor would then freeze or interrupt reshape and write suspend boundaries, such as suspend_lo or suspend_hi, through the md sysfs controls. On vulnerable kernels, suspend waits for the held active I/O reference to drain, but the waiting I/O cannot progress because reshape is frozen, creating a deadlock. This is primarily a local or privileged operational denial-of-service scenario rather than a remote code execution issue.

How to fix it

Update the Linux kernel to a version that includes the md RAID456 fix that wakes wait_for_reshape waiters before normal md suspend when reshape is already interrupted. If vendor packages are used, apply the relevant distribution kernel advisory rather than relying only on upstream version numbers. No fixed package versions were provided in the input, so security teams should consult their Linux distribution, appliance, cloud image, or kernel supplier for the corrected build. As interim mitigation, avoid freezing or suspending md RAID5/RAID6 arrays during reshape while direct I/O workloads are active; schedule reshape operations during controlled maintenance windows; stop or quiesce applications using the array before suspend operations; and avoid automation that writes suspend_lo or suspend_hi during active reshape on unpatched systems.

How to confirm the fix worked

Confirm the running kernel is updated to a vendor build containing the md RAID456 reshape suspend deadlock fix. Inventory systems with md RAID5 or RAID6 arrays by reviewing /proc/mdstat and mdadm --detail output, then verify whether any array is undergoing reshape, recovery, or reshape-related maintenance. On test systems only, validation can include reproducing the vendor or upstream regression test for raid456 reshape deadlock, such as the mdadm tests/25raid456-reshape-deadlock scenario, and confirming suspend completes rather than hanging. In production, validate non-disruptively by checking that no md suspend operations remain stuck, I/O to md devices completes normally, and kernel logs do not show hung tasks involving md, raid5, raid6, mddev_suspend, or raid5_make_request during reshape.

Typical attack path

1. Identify a Linux system running an affected kernel with an md RAID5 or RAID6 array.
2. Wait for or initiate a RAID456 reshape operation, such as array growth, conversion, or layout change.
3. Issue direct I/O across the current reshape position so the I/O path waits for reshape progress.
4. Freeze, interrupt, or pause reshape from userspace.
5. Write md suspend boundaries through the md sysfs interface, commonly suspend_lo or suspend_hi.
6. Trigger the deadlock where suspend waits for active I/O to drain while the I/O waits for reshape progress.
7. Cause hung storage I/O, blocked processes, degraded application availability, or a need for manual recovery.

How to detect it

This issue leaves operational and forensic signs of a storage deadlock rather than conventional compromise artifacts. Review kernel logs, system journal, console logs, and persistent crash or hung-task logs for md RAID456 reshape activity followed by suspend operations and blocked I/O. Useful log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg captures, crash dumps, and storage automation logs. Look for hung tasks involving mddev_suspend(), raid5_make_request(), raid5d, mdX_reshape, direct I/O workloads, or processes blocked in uninterruptible sleep against /dev/md* devices. Also review shell history, sudo logs, auditd, configuration management logs, and orchestration logs for writes to /sys/block/md*/md/suspend_lo or /sys/block/md*/md/suspend_hi near the time reshape was paused or frozen. Because exploitation requires privileged local control of md state, suspicious indicators include unexpected users or automation modifying md sysfs suspend controls, unexplained reshape freezes, and a tight timeline between those actions and storage I/O hangs.

• /sys/block/md*/md/suspend_lo
• /sys/block/md*/md/suspend_hi
• /proc/mdstat
• mddev_suspend
• raid5_make_request
• wait_for_reshape
• mdadm --freeze-reshape
• mdadm --detail
• tests/25raid456-reshape-deadlock
• blocked for more than 120 seconds
• INFO: task
• D state
• reshape
• raid5d
• md*_reshape

What your security team should do

• Prioritize patching systems that use Linux md RAID5 or RAID6 and perform reshape, expansion, migration, or storage maintenance operations.
• Ask Linux distribution or appliance vendors for the kernel build that contains the md RAID456 reshape suspend deadlock fix, then deploy it through normal kernel update processes.
• Inventory md RAID arrays using /proc/mdstat and mdadm output, and flag arrays currently reshaping or scheduled for reshape.
• Until patched, avoid suspending or freezing md RAID456 arrays during reshape while application or direct I/O workloads are active.
• Review storage automation, monitoring, and maintenance scripts for writes to md suspend_lo or suspend_hi during reshape and disable risky workflows until kernels are updated.
• Monitor for hung-task, blocked-I/O, and md RAID reshape/suspend messages in kernel logs, especially around maintenance windows.
• Prepare operational recovery procedures for affected systems, including service quiescence, maintenance-mode failover, and controlled reboot if storage I/O becomes deadlocked.