CVE-2026-90052 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
dm-integrity: fix buffer overflow with keyed discard
Since commit 68c5c42567bc ("dm-integrity: replace forgeable discard filler with a keyed sector marker"), integrity_metadata computes a checksum for every discarded block into the "checksums" buffer. integrity_sector_checksum always writes the whole digest. So if the tag size is smaller than the digest size, the checksum of the last block that fits into the buffer is written past the end of it. For example, with hmac(sha256) and tag size 16, a 4MiB discard writes 16 bytes past the kmalloc'ed page.
Fix this by subtracting extra_space from the buffer size when computing max_blocks, like we do for writes.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The dm-integrity subsystem within the Linux kernel manages data integrity verification for device-mapper targets by maintaining checksums or cryptographic tags associated with stored blocks. A critical vulnerability was identified in how this subsystem handles discard operations when a key is employed to generate these integrity metadata values. Specifically, the issue arises from an incorrect calculation of buffer boundaries during keyed discards, leading to a heap-based buffer overflow that compromises memory safety and system stability.
The root cause lies in the interaction between the tag size used for storing integrity data and the digest size produced by the underlying cryptographic algorithm. When a discard operation is performed on encrypted or key-protected volumes, the kernel computes checksums for every discarded block to ensure consistency before marking them as free. The function responsible for this computation, integrity_sector_checksum, writes the entire digest length into the allocated checksum buffer regardless of whether that specific write completes within the intended logical boundary. If the configured tag size is smaller than the full cryptographic digest size, such as using HMAC-SHA256 with a sixteen-byte tag instead of the full thirty-two-byte hash, the logic fails to account for this discrepancy when determining how many blocks can safely fit into the allocated buffer.
This miscalculation results in writing past the end of the kmalloc-allocated page used for storing checksums during large discard operations. For instance, a four-megabyte discard operation with the aforementioned configuration would write sixteen bytes beyond the bounds of the allocated memory region. This out-of-bounds write constitutes a heap buffer overflow, which can lead to corruption of adjacent kernel data structures, potential privilege escalation if an attacker can control the overwritten memory contents, or system crashes due to invalid memory access patterns triggered by subsequent operations on corrupted metadata.
From a classification perspective, this vulnerability aligns with CWE-120, Buffer Copy without Checking Size of Input, as it involves writing more data than intended into a fixed-size buffer. It also relates to CWE-787, Out-of-bounds Write, due to the memory corruption aspect. In terms of attack vectors and techniques, while this is primarily an exploitation vector for local privilege escalation or denial of service rather than remote code execution, it reflects weaknesses in input validation and boundary checking that are often targeted by attackers seeking to escalate privileges from a low-privilege user context to root level within the kernel space.
The resolution involves correcting the arithmetic used to calculate the maximum number of blocks that can be processed during integrity metadata updates for discards. By subtracting extra_space, which accounts for the difference between the tag size and digest size, from the buffer capacity before computing max_blocks, the code ensures that writes remain strictly within allocated boundaries. This fix mirrors existing logic already present in write operations, thereby maintaining consistency across different I/O paths and preventing similar overflow conditions elsewhere in the subsystem.
To mitigate this vulnerability, system administrators should ensure that all Linux kernels are updated to versions containing the patch for commit 68c5c42567bc or later releases where this fix is integrated. For environments running older kernel versions where immediate updates are not feasible, restricting access to device-mapper integrity targets and monitoring for unusual memory allocation patterns can help reduce exposure until a full system update can be performed. Regular patching cycles aligned with vendor security advisories remain the most effective defense against such low-level kernel vulnerabilities that exploit logical errors in boundary calculations.