CVE-2025-71161: Linux Kernel dm-verity DOS Vulnerability

CVE-2025-71161 Overview

A vulnerability has been discovered in the Linux kernel's dm-verity subsystem related to recursive forward error correction (FEC). The flaw exists in the fec_read_bufs function where a loop with 253 iterations can recursively call verity_hash_for_block. With a limit of 4 nested recursions, this creates the potential for up to 253^4 (approximately 4 billion) iterations, leading to a denial-of-service condition where processes become stuck in an uninterruptible sleep state ('D' state).

Critical Impact

This vulnerability can cause system processes to become unresponsive, particularly affecting udev-worker processes when processing specially crafted dm-verity images. Additionally, the recursive correction mechanism is fundamentally broken as shared fio->bufs data gets overwritten during recursive invocations.

Affected Products

• Linux Kernel (dm-verity subsystem)
• Systems utilizing dm-verity with Forward Error Correction enabled
• Red Hat Enterprise Linux and derivatives using affected kernel versions

Discovery Timeline

• 2026-01-23 - CVE CVE-2025-71161 published to NVD
• 2026-01-26 - Last updated in NVD database

Technical Details for CVE-2025-71161

Vulnerability Analysis

The dm-verity device-mapper target provides transparent integrity checking of block devices using cryptographic digests. The forward error correction (FEC) feature is designed to recover from corruption, but the recursive implementation contains two fundamental flaws.

The first issue is a denial-of-service condition caused by exponential iteration growth. In the fec_read_bufs function, there exists a loop that iterates 253 times. Each iteration may call verity_hash_for_block, which can recursively invoke FEC correction up to 4 levels deep. This creates a worst-case scenario of 253^4 iterations (over 4 billion), causing processes to hang indefinitely in an uninterruptible sleep state.

The second issue is a data corruption problem where the recursive correction simply does not work as intended. The fio->bufs variable is shared across all recursive invocations. When verity_hash_for_block triggers recursive correction, it overwrites partially filled buffer data from outer invocations, corrupting the FEC computation.

Root Cause

The root cause stems from the design of the FEC implementation that allows recursive correction without proper isolation of state between recursion levels. The fio->bufs structure is shared across all recursion depths rather than being allocated per-invocation, and no limit exists on the total number of iterations that can occur when recursion is combined with the 253-iteration loop in fec_read_bufs.

Attack Vector

An attacker with the ability to create or provide a malicious dm-verity image can craft data that triggers the maximum recursion depth during FEC operations. When a system attempts to verify or read from this image, the exponential iteration count causes the process to become stuck. This was demonstrated by the Red Hat QE team who successfully created such an image that causes the udev-worker process to hang in the 'D' state.

The attack requires local access to provide a malicious dm-verity image to the system, which could occur through mounting untrusted disk images or during system boot with a compromised verification image.

Detection Methods for CVE-2025-71161

Indicators of Compromise

• Processes stuck in uninterruptible sleep state ('D') particularly udev-worker
• System hangs or extreme slowdowns during dm-verity operations
• Kernel log messages related to dm-verity FEC operations taking abnormally long
• High CPU utilization in kernel threads handling block device verification

Detection Strategies

• Monitor for processes in 'D' state for extended periods using process monitoring tools
• Track dm-verity subsystem performance metrics for anomalous behavior
• Implement kernel audit logging for dm-verity device creation and mounting events
• Use SentinelOne Singularity platform to detect unusual kernel-level process behavior

Monitoring Recommendations

• Configure alerts for udev-worker or similar processes entering prolonged uninterruptible states
• Monitor block device verification latency for abnormal spikes
• Track kernel CPU time specifically for dm-verity operations
• Implement baseline monitoring for dm-verity FEC operation duration

How to Mitigate CVE-2025-71161

Immediate Actions Required

• Update to a patched Linux kernel version that disables recursive forward error correction
• Avoid mounting untrusted dm-verity images until patched
• Consider temporarily disabling FEC on dm-verity volumes if recursive correction is not critical
• Monitor systems for signs of exploitation attempts during the patching window

Patch Information

The Linux kernel developers have addressed this vulnerability by disabling recursive forward error correction entirely. The fix prevents the exponential iteration scenario and resolves the shared buffer corruption issue.

Patches are available through the kernel git repository:

• Kernel Git Commit 232948cf
• Kernel Git Commit d9f3e47d

Organizations should apply these patches through their standard kernel update processes or build custom kernels incorporating these commits.

Workarounds

• Disable dm-verity FEC on non-critical systems until a patch can be applied
• Implement strict controls on what dm-verity images can be mounted on affected systems
• Use image validation procedures to verify dm-verity images before mounting
• Isolate systems that must process untrusted dm-verity images until patching is complete

# Verify current kernel version and check for patches
uname -r

# Check if dm-verity module is loaded
lsmod | grep dm_verity

# Review dm-verity device status
dmsetup status --target verity