CVE-2026-43309

What it actually does

This is a local denial-of-service flaw in the Linux kernel md RAID and device-mapper dm-raid interaction. When a dm-raid device tree using metadata devices is suspended from the top down and the top-level RAID device is then removed, the dm-raid destructor calls md_stop(). md_stop() attempts to flush the write-intent bitmap to metadata sub-devices that are already suspended, so the I/O cannot complete and the kernel can block indefinitely. The result is a system or storage stack hang during RAID teardown, with availability impact but no direct confidentiality or integrity impact.

Why it matters to the business

Systems using Linux dm-raid can become unresponsive during storage administration, maintenance, shutdown, failover, or automated device removal workflows. The most likely consequence is service interruption requiring administrative recovery or reboot. Because exploitation requires local privileges and a specific storage configuration, broad remote compromise is unlikely, but affected storage hosts, virtualization platforms, appliances, and clustered systems may experience operational outages if the condition is triggered.

How an attack unfolds

An attacker with local privileges sufficient to manipulate device-mapper or RAID devices identifies a host using dm-raid with separate metadata and data devices. The attacker suspends the dm-raid device tree in an order where the top-level RAID device is suspended before its underlying metadata and data devices, then removes the top-level dm-raid device. During teardown, the kernel calls into md_stop(), which attempts to flush the RAID write-intent bitmap. Because the metadata devices needed for the write are already suspended, the flush cannot complete, causing the removal path to block indefinitely. Depending on workload and system role, this may hang storage operations, administrative commands, dependent services, or the whole host.

How to fix it

Upgrade to a Linux kernel version that includes the md raid fix preventing bitmap flushing from the dm-raid destructor path when underlying devices may already be suspended. If vendor fixed package versions are not yet available, track the relevant distribution kernel advisories and apply the first patched kernel released for the affected branch. As interim mitigation, restrict local administrative access to device-mapper, LVM, mdadm, and storage management interfaces; avoid manual or automated workflows that suspend dm-raid device trees from top to bottom before removing the top-level RAID device; and schedule storage teardown operations in maintenance windows with rollback or reboot plans.

How to confirm the fix worked

Confirm that running kernels include the vendor patch for this issue or are at a vendor-declared fixed release. Validate exposure by checking whether systems use dm-raid with metadata devices, for example through device-mapper, LVM RAID, or md RAID configuration views. In a non-production test environment only, reproduce the relevant teardown workflow and confirm that removing a suspended dm-raid top-level device completes without indefinite blocking. After patching, verify that storage removal, suspension, shutdown, and failover procedures complete successfully and that kernel logs do not show hung tasks in dm-raid, md, or bitmap flush paths.

Typical attack path

1. Obtain local access with privileges that allow device-mapper, LVM, or RAID management operations.
2. Identify a dm-raid configuration that uses metadata sub-devices and write-intent bitmap handling.
3. Suspend the device-mapper RAID stack in the vulnerable top-down order.
4. Remove the top-level dm-raid device while its metadata sub-devices remain suspended.
5. Trigger md_stop() from the dm-raid destructor path, causing bitmap flush I/O to wait indefinitely on suspended metadata devices.
6. Cause storage management commands, dependent I/O, or the system to hang until administrative recovery occurs.

How to detect it

To assess whether the issue was already triggered, review kernel logs, journal logs, audit logs, shell history, and storage automation logs around periods of outage, shutdown, device removal, LVM changes, or RAID maintenance. Look for sequences where dmsetup, LVM, or mdadm suspended or removed dm-raid devices followed by hung task warnings, blocked storage commands, unresponsive I/O, or forced reboots. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, auditd execve records for storage-management commands, sudo logs, root shell history, configuration-management job logs, and cluster/storage orchestration logs. Investigate events where dmsetup remove, lvremove, lvchange -an, vgchange -an, mdadm stop, or similar operations did not return and were followed by kernel hung-task diagnostics or watchdog resets. There are no known remote network indicators; evidence is primarily local kernel and administrative activity telemetry.

• blocked for more than 120 seconds
• INFO: task dmsetup
• INFO: task mdadm
• hung_task_timeout_secs
• device-mapper: raid
• dm-raid
• md_stop
• write-intent bitmap
• bitmap flush
• dmsetup suspend
• dmsetup remove
• lvremove
• lvchange -an
• vgchange -an
• mdadm --stop
• D state
• uninterruptible sleep

What your security team should do

• Prioritize patching systems that use dm-raid, LVM RAID, storage appliances, virtualization hosts, or clustered storage nodes where a local storage hang would cause service outage.
• Inventory Linux systems for dm-raid usage and metadata-backed RAID configurations before broad maintenance or decommissioning activity.
• Restrict privileged local access and automation permissions for dmsetup, lvm, mdadm, and related storage management tools.
• Review storage orchestration, shutdown, failover, and removal scripts for top-down suspension followed by top-level dm-raid removal, and adjust workflows to avoid triggering the vulnerable sequence until patched.
• Monitor kernel and system logs for hung task messages involving dm-raid, md, RAID bitmap flushing, or device-mapper remove operations.
• Because this is not in CISA KEV, has no known ransomware association, and has very low EPSS, treat it as operationally important for affected storage hosts rather than as an internet-scale emergency.