CVE-2026-46130
HighCVSS 7.1Exploitation Probability (EPSS)
Low risk5th percentile - higher than 5% of all known CVEs
Summary
A vulnerability has been identified in the Linux kernel within the dm-verity-fec function, which incorrectly assumes that parity bytes are not split across blocks. As a result, during decoding, it may read data outside the allocated buffer, potentially leading to unexpected system behavior.
Risk Assessment
This vulnerability could lead to data integrity violations and potential information leakage, especially in low memory availability situations. Although the occurrence of the issue is limited to specific configurations, it may pose a threat to system stability.
Recommendation
It is recommended to update the Linux kernel to the latest version where fixes for parity block reading have been implemented. Additionally, it is advisable to monitor system configurations to avoid settings that may lead to the occurrence of this vulnerability.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: dm-verity-fec: fix reading parity bytes split across blocks (take 3) fec_decode_bufs() assumes that the parity bytes of the first RS codeword it decodes are never split across parity blocks. This assumption is false. Consider v->fec->block_size == 4096 && v->fec->roots == 17 && fio->nbufs == 1, for example. In that case, each call to fec_decode_bufs() consumes v->fec->roots * (fio->nbufs << DM_VERITY_FEC_BUF_RS_BITS) = 272 parity bytes. Considering that the parity data for each message block starts on a block boundary, the byte alignment in the parity data will iterate through 272*i mod 4096 until the 3 parity blocks have been consumed. On the 16th call (i=15), the alignment will be 4080 bytes into the first block. Only 16 bytes remain in that block, but 17 parity bytes will be needed. The code reads out-of-bounds from the parity block buffer. Fortunately this doesn't normally happen, since it can occur only for certain non-default values of fec_roots *and* when the maximum number of buffers couldn't be allocated due to low memory. For example with block_size=4096 only the following cases are affected: fec_roots=17: nbufs in [1, 3, 5, 15] fec_roots=19: nbufs in [1, 229] fec_roots=21: nbufs in [1, 3, 5, 13, 15, 39, 65, 195] fec_roots=23: nbufs in [1, 89] Regardless, fix it by refactoring how the parity blocks are read.