CVE-2026-43314

What it actually does

This is a local denial-of-service flaw in the Linux kernel device-mapper subsystem. Device-mapper can incorrectly participate in block-layer fake I/O timeout handling even though it does not implement its own timeout recovery path and instead relies on underlying slave devices. When I/O timeout failure injection is enabled against a dm device, a request can be leaked and never completed. The result is stuck block I/O, uninterruptible kernel tasks, queue freeze waits, and potential inability to detach or recover backing storage such as iSCSI devices without rebooting or otherwise forcibly recovering the system.

Why it matters to the business

A user or process with sufficient local privileges to manipulate kernel block-device fault-injection controls can make affected Linux systems hang I/O paths, disrupt applications using device-mapper storage, and potentially require operational intervention or reboot. The main risk is availability loss on servers using dm-based storage stacks such as LVM, multipath, encrypted volumes, or dm devices backed by network storage. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so it is generally a patch-management and hardening priority rather than an internet-scale emergency.

How an attack unfolds

An attacker first needs local access with privileges sufficient to write to kernel sysfs/debugfs fault-injection interfaces for block devices. They identify a device-mapper block device, such as dm-0, and enable I/O timeout failure behavior for that target while configuring the kernel fail_io_timeout fault-injection parameters. They then trigger reads, writes, or storage teardown activity involving the dm device or its backing device. Because the dm layer has no native timeout handler, the faked timeout can leave a request permanently incomplete. Subsequent storage operations can block in kernel paths such as blk_mq_freeze_queue_wait, producing hung tasks and degraded or unavailable services that depend on the affected storage.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix removing the inappropriate blk_should_fake_timeout() handling from the device-mapper driver. Because no exact fixed package versions were provided, use the corrected kernel version from the relevant Linux distribution or kernel vendor security advisory. As compensating controls, restrict local administrative access, avoid exposing debugfs in production where not required, mount debugfs only for trusted administrators, restrict writes to /sys/class/block/*/io-timeout-fail and /sys/kernel/debug/fail_io_timeout/*, and monitor or disable kernel fault-injection features on production systems. Systems using device-mapper heavily, especially with network-backed storage such as iSCSI, should be prioritized for kernel update and reboot into the fixed kernel.

How to confirm the fix worked

Confirm the running kernel is a vendor build that contains the device-mapper fix for this issue, not merely that an updated package is installed. Validate with uname -r, package manager metadata, and vendor changelogs or advisory references. Where safe in a non-production test environment, verify that dm no longer accepts or acts on fake I/O timeout behavior in a way that leaks requests. In production, validate exposure by checking whether debugfs is mounted, whether /sys/kernel/debug/fail_io_timeout is present, whether /sys/class/block/dm-*/io-timeout-fail exists and is writable by non-administrative users, and whether device-mapper storage is in use. Confirm there are no recurring kernel hung-task messages involving dm, blk_mq_freeze_queue_wait, iSCSI unbind, or block queue teardown after remediation.

Typical attack path

1. Obtain local shell or code execution on an affected Linux host with privileges allowing writes to block-device sysfs/debugfs fault-injection controls.
2. Confirm that device-mapper devices are present, for example dm-* devices used by LVM, multipath, encryption, or other dm targets.
3. Enable I/O timeout fault injection for the selected dm device through the block-device io-timeout-fail interface and configure fail_io_timeout probability/times parameters.
4. Generate I/O or trigger storage session/device teardown involving the affected dm device or its backing device.
5. Cause leaked block requests that never complete, leading to uninterruptible tasks, blocked queues, failed device removal, service stalls, or host-level availability impact.

How to detect it

Look for evidence that kernel block I/O fault-injection controls were enabled against device-mapper devices, followed by storage hangs. Relevant sources include kernel logs, dmesg, journald, auditd records for sysfs/debugfs writes, EDR process telemetry, shell history for privileged accounts, and configuration management logs. Search for writes to /sys/class/block/dm-*/io-timeout-fail and /sys/kernel/debug/fail_io_timeout/probability or /sys/kernel/debug/fail_io_timeout/times. In kernel logs, look for hung task reports, blocked kworkers, uninterruptible D-state processes, call traces containing blk_mq_freeze_queue_wait, blk_unregister_queue, __del_gendisk, sd_remove, scsi_remove_target, or __iscsi_unbind_session. Also correlate iSCSI logout or device removal attempts with sudden I/O stalls and repeated hung_task_timeout_secs warnings. Since no public exploitation or named threat actor activity is indicated, detection should focus on local misuse, unsafe fault-injection testing, or compromised privileged accounts manipulating kernel debug interfaces.

• /sys/class/block/dm-0/io-timeout-fail
• /sys/class/block/dm-*/io-timeout-fail
• /sys/kernel/debug/fail_io_timeout/probability
• /sys/kernel/debug/fail_io_timeout/times
• echo 1 > /sys/class/block/dm-0/io-timeout-fail
• echo 100 > /sys/kernel/debug/fail_io_timeout/probability
• echo 10 > /sys/kernel/debug/fail_io_timeout/times
• io-timeout-fail
• fail_io_timeout
• INFO: task
• blocked for more than 120 seconds
• blocked for more than 122 seconds
• hung_task_timeout_secs
• blk_mq_freeze_queue_wait
• blk_unregister_queue
• __del_gendisk
• del_gendisk
• sd_remove
• scsi_remove_target
• __iscsi_unbind_session
• Workqueue: iscsi_ctrl
• state:D
• device-mapper
• dm-0

What your security team should do

• Prioritize patching Linux systems that use device-mapper for production storage, especially LVM, dm-crypt, multipath, and iSCSI-backed dm devices.
• Upgrade and reboot into a kernel version confirmed by the vendor to contain the device-mapper timeout handling fix.
• Restrict access to kernel fault-injection controls and debugfs; avoid mounting debugfs on production hosts unless operationally required.
• Use auditd or equivalent telemetry to alert on writes to /sys/class/block/dm-*/io-timeout-fail and /sys/kernel/debug/fail_io_timeout/*.
• Investigate recent kernel hung-task events involving device-mapper, iSCSI, block queue freeze, or uninterruptible I/O waits.
• Treat unexplained storage hangs following changes to fault-injection sysfs/debugfs settings as possible abuse or unsafe testing.
• Because the issue is not in KEV and has low EPSS, handle it through normal prioritized kernel maintenance unless affected hosts support critical storage workloads.