Linux Kernel EUVD-2026-28579

Requires dm-raid target usage for RAID array management with metadata devices configured. Standard mdadm-managed RAID arrays without device-mapper are not affected. Exploitation requires the specific device teardown sequence: suspend operation must proceed top-to-bottom through the dm-raid device tree before removing the top-level device. Most common RAID management workflows using mdadm tools do not trigger this code path. Local access with permissions to manage device-mapper devices (typically root or CAP_SYS_ADMIN capability) is required. The vulnerability manifests as an operational failure during administrative tasks rather than traditional security exploitation, limiting attack scenarios to denial-of-service during legitimate device management by administrators or malicious insiders with elevated privileges.

Real-world risk is low despite the high availability impact (CVSS A:H). The CVSS vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H indicates local access with low privileges required, but exploitation demands very specific conditions: the system must use dm-raid (not standard mdadm), arrays must have metadata devices configured, and the precise suspend-then-remove sequence must occur. The EPSS score of 0.02% (4th percentile) reflects this low real-world exploitation likelihood. No CISA KEV listing exists, and no public exploit code is identified. The vulnerability is primarily a reliability issue affecting systems using dm-raid in containerized or virtualized environments where programmatic device management occurs, rather than a security threat vector. Administrators running dm-raid with metadata devices should prioritize patching, but this is not a widespread critical exposure. The narrow attack surface (local admin triggering specific device-mapper operations) and availability-only impact limit the urgency compared to remote code execution or privilege escalation vulnerabilities.

A local user with low privileges on a system using dm-raid for RAID array management initiates a device teardown sequence, first suspending the top-level RAID device and its underlying metadata/data devices through device-mapper ioctls, then removes the top-level device. This triggers md_stop() to attempt flushing write-intent bitmaps to the suspended metadata devices, causing the kernel thread to hang indefinitely and rendering the system unresponsive for RAID operations or requiring a full reboot to recover.