CVE-2026-99135 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
dm-integrity: fix infinite loop on discard with large tag size
When integrity_metadata handles a discard, it fills a buffer with DISCARD_FILLER and writes it over the tags, max_blocks blocks at a time. If the kmalloc fails, the buffer is the on-stack array checksums_onstack and max_size is set to HASH_MAX_DIGESTSIZE. So if the tag size is larger than HASH_MAX_DIGESTSIZE, max_blocks is zero, bi_size is never decremented and the loop never terminates.
Fix this by using sizeof(checksums_onstack) as max_size. The array has MAX_TAG_SIZE bytes since commit b93b6643e9b5 ("dm integrity: fix a crash with unusually large tag size"), so max_blocks is at least 1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The dm-integrity subsystem within the Linux kernel manages data integrity for device-mapper targets by maintaining metadata tags that verify the authenticity and consistency of stored blocks. A critical flaw exists in how this subsystem handles discard operations when memory allocation fails during tag processing. Specifically, the function responsible for handling these discards attempts to fill a buffer with a DISCARD_FILLER pattern and write it over integrity tags in chunks defined by max_blocks. Under normal circumstances, if dynamic memory allocation via kmalloc succeeds, the system uses an appropriately sized heap-allocated buffer. However, when this allocation fails, the code falls back to using a static on-stack array named checksums_onstack as the temporary storage for tag data.
The vulnerability arises from an incorrect calculation of the maximum block size in this fallback path. The original implementation incorrectly sets max_size to HASH_MAX_DIGESTSIZE rather than the actual size of the stack buffer. Since HASH_MAX_DIGESTSIZE represents the maximum output length of a cryptographic hash function and is typically smaller than MAX_TAG_SIZE, this assignment creates a logical error when tag sizes exceed standard digest lengths. Consequently, the calculation for max_blocks results in zero because it divides by an insufficient or mismatched denominator relative to the actual data being processed. This leads to bi_size remaining unchanged throughout the loop iteration sequence.
This arithmetic failure triggers an infinite loop condition that can severely impact system stability and availability. Because bi_size is never decremented, the processing loop continues indefinitely without making progress on clearing the discard request. For local users or processes interacting with affected device-mapper targets, this results in a denial of service characterized by high CPU utilization as the kernel thread spins uncontrollably within the integrity handling routine. Remote attackers may exploit similar conditions if they can trigger specific I/O patterns that induce memory pressure and force the fallback path, thereby causing resource exhaustion on the target system.
From a classification perspective, this issue aligns with CWE-835, which describes loops that do not terminate correctly due to logic errors in loop control variables. It also relates to CWE-401 regarding missing release of resources after failure, although here the consequence is computational rather than memory-leak based. In terms of adversarial tactics, this vulnerability supports ATT&CK technique T1499, Endpoint Denial of Service, as it allows an attacker to degrade or interrupt system availability through resource exhaustion via a kernel-level infinite loop.
The resolution involves correcting the max_size variable in the fallback path to use sizeof(checksums_onstack) instead of HASH_MAX_DIGESTSIZE. This adjustment ensures that max_blocks is calculated correctly based on the actual capacity of the stack buffer, which was previously expanded to MAX_TAG_SIZE in an earlier commit addressing crash scenarios with large tag sizes. By guaranteeing that at least one block can be processed per iteration, the loop terminates properly after handling all required data. System administrators should apply kernel updates or patches provided by their distribution vendors to mitigate this risk and restore normal integrity metadata processing behavior under memory-constrained conditions.