CVE-2026-99098 in Linux
Summary
by MITRE • 10/26/2026
In the Linux kernel, the following vulnerability has been resolved:
dm-integrity: fix buffer overflow in inline mode with large tag size
In inline mode, dm_integrity_check and dm_integrity_inline_recheck compute the checksum of each block into an on-stack buffer of HASH_MAX_DIGESTSIZE bytes. integrity_sector_checksum pads its result with zeroes up to the tag size, so if the tag size is larger than HASH_MAX_DIGESTSIZE, the padding runs past the end of the buffer. With CONFIG_STACKPROTECTOR the kernel panics in dm_integrity_check on the first read.
Enlarge both buffers to hold MAX_TAG_SIZE bytes, as commit b93b6643e9b5 ("dm integrity: fix a crash with unusually large tag size") did for integrity_metadata.
Note that this is not a security bug because the buffer overflow can only be triggered by root.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The Linux kernel device-mapper integrity target, specifically within its inline mode operation, contained a critical stack-based buffer overflow vulnerability affecting systems configured with large tag sizes. This flaw resides in the functions dm_integrity_check and dm_integrity_inline_recheck, which are responsible for computing checksums for data blocks during verification processes. The implementation utilized an on-stack buffer sized to HASH_MAX_DIGESTSIZE bytes to store these computed hashes. However, the integrity_sector_checksum function pads its output with zeros until it reaches a specified tag size. When this configured tag size exceeds the fixed capacity of HASH_MAX_DIGESTSIZE, the padding operation writes beyond the allocated stack memory boundaries. This out-of-bounds write corrupts adjacent stack data and triggers immediate kernel panic when CONFIG_STACKPROTECTOR is enabled, effectively causing a denial of service for any system relying on dm-integrity with such configurations.
From a technical perspective, this vulnerability represents an improper limitation of internal buffer sizes relative to external configuration parameters. The root cause lies in the assumption that the tag size would never exceed the maximum hash digest size supported by the underlying cryptographic libraries. By failing to dynamically allocate or statically define buffers large enough to accommodate MAX_TAG_SIZE, the code violates fundamental memory safety principles. This aligns with CWE-121, which categorizes stack-based buffer overflows resulting from insufficient bounds checking on user-controlled or configuration-driven data sizes. The vulnerability is triggered during the integrity verification phase of I/O operations, meaning that any attempt to read protected blocks under these specific conditions will result in system instability rather than successful execution of malicious code.
The operational impact of this flaw is primarily a denial of service condition for systems utilizing dm-integrity with large tag configurations. Because the buffer overflow occurs on the kernel stack and triggers the stack protector, the immediate consequence is a kernel panic or crash. This renders the affected storage subsystems inaccessible until the system is rebooted. While such crashes can theoretically be leveraged in complex attack chains to achieve privilege escalation if other conditions are met, this specific instance does not allow for arbitrary code execution due to the nature of stack corruption and the immediate termination by security mitigations like CONFIG_STACKPROTECTOR. The vulnerability affects data integrity assurance mechanisms, potentially leading to loss of availability for critical storage volumes managed through device-mapper.
Regarding classification within industry standards, this issue is best described as CWE-121: Stack-based Buffer Overflow. In terms of the MITRE ATT&CK framework, it does not directly map to a specific tactic like Initial Access or Privilege Escalation because it requires root privileges to trigger and results in system crash rather than control flow hijacking. However, it impacts Availability under the Impact category. The vulnerability is strictly local and requires administrative access to configure dm-integrity with an oversized tag size, which significantly limits its exploitability by external threat actors.
The resolution involves enlarging both affected buffers from HASH_MAX_DIGESTSIZE to MAX_TAG_SIZE bytes within the integrity checking functions. This change ensures that the padding operation remains within allocated memory boundaries regardless of the configured tag size. This fix mirrors previous corrections applied to integrity_metadata handling, establishing consistency across different parts of the dm-integrity subsystem. Administrators and developers should ensure that kernel updates incorporating this patch are deployed on systems using device-mapper integrity targets with large tag configurations. Additionally, verifying that CONFIG_STACKPROTECTOR is enabled provides an additional layer of defense against similar stack corruption issues in other components. Regular auditing of storage configuration parameters to prevent excessively large values can also mitigate the risk of triggering such buffer overflows in unpatched environments.