CVE-2026-72100 in Linuxinfo

Summary

by MITRE • 08/15/2026

In the Linux kernel, the following vulnerability has been resolved:

dm-integrity: fix a bug if the bio is out of limits

If dm_integrity_check_limits fails, the code would exit with DM_MAPIO_KILL. However, the range would be already locked at this point, and it wouldn't be unlocked, resulting in a deadlock. Let's move the limit check up, so that when it exits, no resources are leaked.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 08/15/2026

The vulnerability under discussion involves a critical flaw within the Linux kernel's device mapper integrity subsystem, specifically affecting the dm-integrity module. This issue manifests as a potential deadlock condition that can severely impact system stability and availability. The problem occurs during the processing of block I/O operations where the integrity checking mechanism fails to properly manage resource allocation and deallocation sequences.

The technical flaw stems from improper ordering of operations within the device mapper integrity code path. When the dm_integrity_check_limits function determines that a bio operation exceeds established limits, the code path executes a premature exit using DM_MAPIO_KILL return code. However, at this point in the execution flow, the system has already acquired locks on the relevant data ranges, creating a scenario where these resources remain indefinitely locked. This lock contention prevents other processes from accessing the same data regions, leading to a deadlock condition that can cascade throughout the storage subsystem.

The operational impact of this vulnerability extends beyond simple system hangs, as it represents a fundamental resource management failure within the kernel's I/O handling pipeline. When the limit check occurs after locks are acquired, the system cannot properly clean up these locked resources during error exit paths, creating persistent lock contention that affects not only the specific operation triggering the issue but potentially other concurrent I/O operations. This vulnerability directly relates to CWE-691, which addresses insufficient control of resources, and specifically aligns with the ATT&CK technique T1484.001 related to Privilege Escalation through kernel exploitation.

The root cause analysis reveals that the problematic code structure violates proper resource management principles by performing limit validation after resource acquisition rather than before. This anti-pattern creates a situation where error handling paths cannot properly release acquired locks, resulting in resource leaks and system instability. The fix implemented addresses this by reordering the operations to perform limit checks prior to any resource locking, ensuring that when exit conditions occur due to limit violations, no resources remain locked or allocated.

This vulnerability demonstrates the critical importance of proper lock ordering and resource management in kernel space programming, particularly within high-throughput storage subsystems. The fix ensures that when dm_integrity_check_limits fails, no locks are held, preventing the deadlock condition while maintaining the integrity checking functionality. This approach aligns with best practices for kernel development as outlined in the Linux kernel documentation and security guidelines, emphasizing the need for defensive programming techniques that prevent resource leaks and lock contention scenarios.

The mitigation strategy involves implementing proper ordering of validation operations before resource acquisition, ensuring that all error paths can properly clean up allocated resources regardless of execution flow. This fix represents a fundamental improvement to the device mapper integrity subsystem's robustness and reliability under stress conditions where I/O operations may exceed configured limits. The solution addresses both immediate deadlock concerns and prevents potential denial-of-service scenarios that could affect storage availability for critical system operations.

Responsible

Linux

Reservation

08/09/2026

Disclosure

08/15/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Want to stay up to date on a daily basis?

Enable the mail alert feature now!