CVE-2025-71117: Linux Kernel DOS Vulnerability

CVE-2025-71117 Overview

A deadlock vulnerability has been identified in the Linux kernel's block layer where freezing the request queue from inside sysfs store callbacks can cause a system deadlock when used in combination with the dm-multipath driver and the queue_if_no_path option. This vulnerability affects the interaction between user-space configuration operations and kernel-level queue management, potentially leading to system hangs and denial of service conditions.

Critical Impact
Systems using dm-multipath with queue_if_no_path enabled are vulnerable to deadlock conditions when sysfs attributes are modified, potentially causing complete system unresponsiveness and requiring a hard reboot to recover.

Affected Products

Linux kernel (versions with vulnerable block layer sysfs store callbacks)
Systems using dm-multipath driver with queue_if_no_path option
Systems where sysfs attributes are set synchronously during boot

Discovery Timeline

2026-01-14 - CVE CVE-2025-71117 published to NVD
2026-01-14 - Last updated in NVD database

Technical Details for CVE-2025-71117

Vulnerability Analysis

The vulnerability stems from a race condition and deadlock scenario in the Linux kernel's block layer. When sysfs store callbacks invoke blk_mq_freeze_queue() and blk_mq_unfreeze_queue() functions, a deadlock can occur under specific conditions involving the dm-multipath driver.

The issue manifests when two tasks compete for related resources: one task (such as multipathd) holds a mutex lock while attempting to complete device mapper operations, while another task (such as udev-worker) waits in blk_mq_freeze_queue_wait() while trying to modify sysfs attributes. This creates a circular dependency that cannot be resolved, resulting in both tasks being permanently blocked.

The affected sysfs attributes include:

io_poll_delay
io_timeout
nomerges
read_ahead_kb
rq_affinity

Additionally, the queue freezing operation during sysfs attribute modification can significantly slow down system boot on systems that set these attributes synchronously during startup.

Root Cause

The root cause is the use of queue freezing (blk_mq_freeze_queue() / blk_mq_unfreeze_queue()) within sysfs store callbacks where it is not strictly necessary. When the dm-multipath driver uses the queue_if_no_path option, the queue freezing operation can create a lock ordering conflict with the device mapper's internal mutex operations.

The deadlock pattern occurs because:

The multipathd process holds a mutex while calling dm_table_set_restrictions() during device mapper table operations
A udev-worker process attempts to modify a sysfs attribute (e.g., read_ahead_kb) which triggers queue_ra_store()
The sysfs store callback calls blk_mq_freeze_queue_nomemsave() and waits in blk_mq_freeze_queue_wait()
Neither process can proceed as they are waiting on resources held by the other

Attack Vector

The vulnerability is primarily a local denial of service condition that can be triggered through normal system operations. An attacker with local access could potentially exploit this by manipulating sysfs attributes on systems configured with dm-multipath and queue_if_no_path, causing the system to become unresponsive.

The deadlock can be triggered during:

System boot when udev rules modify block device attributes
Runtime configuration changes to block device parameters
Automated system management operations that interact with sysfs

The call trace demonstrates the deadlock scenario where the multipathd task is blocked in mutex_lock_nested() during dm_table_set_restrictions(), while the udev-worker task is blocked in blk_mq_freeze_queue_wait() during the queue_ra_store() sysfs callback.

Detection Methods for CVE-2025-71117

Indicators of Compromise

System hangs or becomes unresponsive when modifying block device sysfs attributes
Processes stuck in "D" (uninterruptible sleep) state related to multipathd or udev-worker
Kernel stack traces showing tasks blocked in blk_mq_freeze_queue_wait() or mutex_lock_nested()
Extended system boot times when dm-multipath is configured with queue_if_no_path

Detection Strategies

Monitor for processes in uninterruptible sleep state involving block layer operations using tools like ps aux | grep -E '^.{5}D'
Review kernel logs for deadlock detection messages or hung task warnings
Implement watchdog monitoring to detect system responsiveness degradation during dm-multipath operations
Use kernel debugging tools like sysrq-t to capture stack traces when system becomes unresponsive

Monitoring Recommendations

Configure kernel hung task detection (CONFIG_DETECT_HUNG_TASK) with appropriate timeout values
Monitor system boot times for unexpected delays on dm-multipath configured systems
Implement automated alerting for processes stuck in uninterruptible sleep for extended periods
Review multipath configuration to identify systems using queue_if_no_path option

How to Mitigate CVE-2025-71117

Immediate Actions Required

Apply the kernel patch that removes unnecessary queue freezing from sysfs store callbacks
Review multipath configurations and consider temporarily disabling queue_if_no_path on critical systems until patched
Avoid modifying affected sysfs attributes (io_poll_delay, io_timeout, nomerges, read_ahead_kb, rq_affinity) on systems with active dm-multipath configurations
Schedule maintenance windows for kernel updates on affected systems

Patch Information

The fix removes the blk_mq_freeze_queue() / blk_mq_unfreeze_queue() calls from sysfs store callbacks that do not strictly require them. Additionally, the __data_racy annotation is added to request_queue.rq_timeout to suppress KCSAN data race reports.

Patches are available via the following kernel commits:

Note: The patch may cause a small delay in applying new sysfs attribute settings, but I/O operations will complete correctly regardless of whether the old or new attribute value is used.

Workarounds

Defer sysfs attribute modifications for affected parameters until after system boot completes
Configure udev rules to skip or delay modifications to affected sysfs attributes on dm-multipath devices
Consider using asynchronous configuration methods rather than synchronous sysfs writes during boot
If possible, avoid the queue_if_no_path dm-multipath option until the kernel is patched

bash

# Configuration example
# Identify systems using dm-multipath with queue_if_no_path
multipathd show config | grep -i queue_if_no_path

# Check current kernel version
uname -r

# Verify if affected sysfs attributes are being modified during boot
grep -r "read_ahead_kb\|io_timeout\|nomerges\|rq_affinity\|io_poll_delay" /etc/udev/rules.d/