CVE-2026-72098 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
dm-verity: fix buffer overflow in FEC calculation
There's a buffer overflow in dm-verity-fec:
if (neras && *neras <= v->fec->roots) fio->erasures[(*neras)++] = i;
This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one
element past the end of lambda[] (which is sized nroots + 1, valid
indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting
the syndrome buffer.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability in question affects the Linux kernel's device mapper verity implementation with forward error correction functionality, specifically within the Reed-Solomon error correction decoding process. This issue resides in the dm-verity-fec subsystem which provides integrity verification for device mapper volumes using forward error correction to detect and correct data corruption. The flaw manifests as a buffer overflow during the FEC (Forward Error Correction) calculation phase when processing erasure information from the device mapper verity framework.
The technical root cause stems from an improper boundary check in the erasure handling logic where the variable neras can exceed the allocated bounds of the erasures array. When the condition if (neras && neras <= v->fec->roots) evaluates to true, the code performs post-increment operations that allow *neras to reach a value of roots + 1 before the increment occurs. This overflowed value then gets passed as the no_eras parameter to the decode_rs8() function, which subsequently uses this invalid index in the Reed-Solomon decoding algorithm.
The operational impact of this vulnerability extends beyond simple memory corruption, as it creates an out-of-bounds write condition within the Reed-Solomon decoder implementation located at lib/reed_solomon/decode_rs.c. The specific problem occurs in lines 113-121 where the erasure locator polynomial loop writes to the lambda[] array using index j that can reach nroots + 1, exceeding the valid array bounds from 0 to nroots. This out-of-bounds write target lands on syn[0] within the syndrome buffer, causing corruption of critical verification data that undermines the integrity protection mechanism.
This vulnerability directly maps to CWE-121 Stack-based Buffer Overflow and CWE-787 Out-of-bounds Write, representing a classic case where improper input validation leads to memory corruption in cryptographic verification systems. The attack surface is particularly concerning as it affects the core integrity verification capabilities of device mapper volumes, potentially allowing an attacker to bypass data integrity checks or cause system instability during verification operations. The flaw aligns with ATT&CK technique T1070.004 Indicator Removal on Host for potential exploitation through manipulation of verification data, and T1566 Phishing for initial compromise vectors that could lead to exploitation of this kernel vulnerability.
Mitigation strategies should focus on implementing proper bounds checking in the erasure handling logic to prevent *neras from exceeding the allocated array size, ensuring that all input parameters passed to cryptographic functions maintain valid boundaries. Kernel updates addressing this specific buffer overflow in the dm-verity-fec implementation provide the primary remediation path, while system administrators should prioritize patching affected kernel versions to prevent exploitation. Additionally, monitoring for unusual verification failures or system instability during integrity checks can help detect potential exploitation attempts targeting this vulnerability.