CVE-2026-46051

What it actually does

This flaw is a local denial-of-service condition in the Linux kernel md/raid5 driver. Under a specific RAID5 aligned-read retry path, an overlapped stripe can be moved between internal lists in a way that prevents the kernel RAID5 daemon from ever processing the stripe that would resolve the overlap. The result is an infinite retry loop in raid5d, high CPU consumption, and a kernel soft lockup. Confidentiality and integrity are not directly affected, but availability of the host, storage stack, or workloads relying on the affected RAID5 array can be severely degraded or lost.

Why it matters to the business

Systems using Linux software RAID5 may become unresponsive or experience storage outages if a local user or workload triggers the defective I/O path. The likely operational impact is service disruption, failed applications, degraded storage performance, and potential need for emergency reboot or failover. Because exploitation requires local access and there is no known public exploitation or KEV listing, urgency is lower than for remote code execution flaws, but affected production storage hosts should still be patched through normal kernel maintenance windows.

How an attack unfolds

An attacker first needs local access to a Linux system that uses the kernel md RAID5 implementation. The attacker then generates I/O patterns that cause aligned reads to encounter overlapping RAID5 stripes. When retry_aligned_read() hits the failure path for an overlapped stripe, the vulnerable kernel can release the stripe through a path that places it on the released_stripes lockless list. In the next raid5d iteration, the stripe may be moved to handle_list, but retry_aligned_read() can run before handle_active_stripes() and remove the stripe from handle_list using find_get_stripe(). Because handle_stripe() never processes that stripe, the overlap is never resolved. The RAID5 daemon can then loop indefinitely, producing a soft lockup and degrading or halting storage availability.

How to fix it

Upgrade the Linux kernel to a version that includes the md/raid5 fix for retry_aligned_read(), specifically the change that uses __release_stripe() with temp_inactive_list in the failure path instead of routing the stripe through raid5_release_stripe() and released_stripes. No fixed package versions were provided in the input, so use the relevant distribution advisory and install the latest supported kernel for affected Linux systems. Reboot into the fixed kernel after installation. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users and workloads from generating arbitrary I/O on RAID5-backed filesystems, migrating critical workloads away from vulnerable RAID5 md arrays where feasible, and ensuring failover/reboot procedures are ready for affected storage hosts.

How to confirm the fix worked

Confirm exposure by identifying systems using Linux md RAID5, for example by checking /proc/mdstat, mdadm --detail, or distribution inventory data. Confirm remediation by verifying the running kernel version after reboot and matching it to a vendor kernel package that contains the md/raid5 retry_aligned_read() fix. Functional validation should include exercising normal RAID5-backed read workloads and confirming that kernel logs no longer show raid5d soft lockups during sustained I/O. Also verify that patched hosts are actually booted into the updated kernel rather than only having the package installed.

Typical attack path

1. Obtain local access to a Linux host that uses md/raid5 software RAID.
2. Identify or access a filesystem, block device, or workload backed by the affected RAID5 array.
3. Generate sustained or carefully timed read I/O patterns that create overlapping stripe conditions during aligned reads.
4. Trigger the vulnerable retry_aligned_read() failure path that mishandles the stripe release/list transition.
5. Cause raid5d to spin in an unresolved retry loop, leading to high CPU usage, kernel soft-lockup messages, storage stalls, or host unresponsiveness.

How to detect it

To assess possible prior exploitation or triggering, review kernel logs, journal logs, and system monitoring for signs of raid5d soft lockups, persistent high CPU usage in raid5d, I/O stalls, hung tasks, storage timeouts, or emergency reboots on systems using md RAID5. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, crash dumps, monitoring telemetry for CPU and disk latency, and mdadm event logs where available. Because the symptom can also be caused by heavy workload or kernel defects rather than malicious activity, correlate events with local user sessions, scheduled jobs, containers, batch workloads, or processes issuing unusually high read I/O to RAID5-backed paths. Look especially for repeated soft-lockup messages naming raid5d or kernel stack traces containing retry_aligned_read, raid5d, handle_active_stripes, handle_stripe, release_stripe_list, or raid5_release_stripe.

• BUG: soft lockup
• watchdog: BUG: soft lockup
• CPU# stuck for
• raid5d
• retry_aligned_read
• md/raid5
• handle_active_stripes
• handle_stripe
• release_stripe_list
• raid5_release_stripe
• find_get_stripe
• blocked for more than
• INFO: task raid5d
• /proc/mdstat
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Inventory Linux systems using md/raid5 software RAID and prioritize production storage hosts, virtualization hosts, and application servers with RAID5-backed data volumes.
• Apply vendor-supported kernel updates that include the md/raid5 retry_aligned_read() fix, then reboot into the fixed kernel.
• Monitor affected systems for kernel soft-lockup events, raid5d CPU spikes, I/O hangs, and storage timeout symptoms until patching is complete.
• Restrict local access and untrusted workloads on systems that cannot be patched promptly, because exploitation requires local interaction with the affected storage path.
• Review incident and availability logs for unexplained RAID5-related stalls or soft lockups since the vulnerability publication date.
• Ensure backups, failover, and recovery procedures are current for systems dependent on Linux software RAID5.