Live › vulnerability › CVE-2026-99098
Go to dashboardIn inline mode, dm-integrity computes block checksums into a stack buffer sized HASH_MAX_DIGESTSIZE, but padding to a larger tag size writes past its end. The kernel panics on the first read, and the sources state only root can trigger it and that it is not a security bug.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-26 16:02 UTC. All times on this page are UTC.
Systems that use dm-integrity in inline mode with a tag size larger than HASH_MAX_DIGESTSIZE. The sources do not name the affected kernel versions or the fixed release. Machines that do not use dm-integrity are not affected.
No product ranges from the sources yet.
Unknown from the sources.
Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-99098")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.