CVE-2026-46130

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.