PT-2026-44253 · Linux · Linux
Published
2026-05-28
·
Updated
2026-05-28
·
CVE-2026-46130
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux