CVE-2026-43314
Received Received - Intake
Request Leak in Linux Kernel Device Mapper

Publication date: 2026-05-08

Last updated on: 2026-05-08

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: dm: remove fake timeout to avoid leak request Since commit 15f73f5b3e59 ("blk-mq: move failure injection out of blk_mq_complete_request"), drivers are responsible for calling blk_should_fake_timeout() at appropriate code paths and opportunities. However, the dm driver does not implement its own timeout handler and relies on the timeout handling of its slave devices. If an io-timeout-fail error is injected to a dm device, the request will be leaked and never completed, causing tasks to hang indefinitely. Reproduce: 1. prepare dm which has iscsi slave device 2. inject io-timeout-fail to dm 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 3. read/write dm 4. iscsiadm -m node -u Result: hang task like below [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds. [ 862.244133] Tainted: G E 6.19.0-rc1+ #51 [ 862.244337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000 [ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi] [ 862.245264] Call Trace: [ 862.245587] <TASK> [ 862.245814] __schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120 [ 862.247688] elevator_change+0x16d/0x460 [ 862.247893] elevator_set_none+0x87/0xf0 [ 862.248798] blk_unregister_queue+0x12e/0x2a0 [ 862.248995] __del_gendisk+0x231/0x7e0 [ 862.250143] del_gendisk+0x12f/0x1d0 [ 862.250339] sd_remove+0x85/0x130 [sd_mod] [ 862.250650] device_release_driver_internal+0x36d/0x530 [ 862.250849] bus_remove_device+0x1dd/0x3f0 [ 862.251042] device_del+0x38a/0x930 [ 862.252095] __scsi_remove_device+0x293/0x360 [ 862.252291] scsi_remove_target+0x486/0x760 [ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi] [ 862.252886] process_one_work+0x633/0xe50 [ 862.253101] worker_thread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] ret_from_fork+0x2a6/0x470 [ 862.255852] ret_from_fork_asm+0x1a/0x30 [ 862.256037] </TASK> Remove the blk_should_fake_timeout() check from dm, as dm has no native timeout handling and should not attempt to fake timeouts.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-08
Last Modified
2026-05-08
Generated
2026-05-09
AI Q&A
2026-05-08
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux_kernel linux_kernel 6.19.0-rc1
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's device mapper (dm) driver. The dm driver does not implement its own timeout handler and relies on its slave devices for timeout handling. Since a certain commit, drivers are expected to call blk_should_fake_timeout() to handle timeouts properly. However, the dm driver incorrectly uses this fake timeout mechanism without having native timeout handling.

When an io-timeout-fail error is injected into a dm device, the request is leaked and never completed. This causes tasks to hang indefinitely, leading to system instability or unresponsive behavior.


How can this vulnerability impact me? :

The impact of this vulnerability is that tasks interacting with the dm device can hang indefinitely due to leaked requests that are never completed. This can cause system processes to become unresponsive, potentially leading to degraded system performance or denial of service conditions.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing if tasks hang indefinitely when an io-timeout-fail error is injected to a device mapper (dm) device that has an iSCSI slave device.

To reproduce and detect the issue, you can use the following commands:

  • 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

Then perform read/write operations on the dm device and run:

  • iscsiadm -m node -u

If the vulnerability is present, you will see tasks hanging with messages similar to kernel logs indicating blocked tasks, such as:

  • INFO: task kworker/u514:2:151 blocked for more than 122 seconds.

What immediate steps should I take to mitigate this vulnerability?

The vulnerability has been resolved by removing the fake timeout check (blk_should_fake_timeout()) from the dm driver, as dm does not have native timeout handling and should not attempt to fake timeouts.

Immediate mitigation steps include:

  • Update your Linux kernel to a version that includes the fix (commit 15f73f5b3e59 or later).
  • Avoid injecting io-timeout-fail errors into dm devices, especially those with iSCSI slave devices.
  • Monitor for hung tasks related to dm devices and iSCSI sessions and consider restarting affected services or systems if hangs occur.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart