CVE-2026-46130

{"id": "CVE-2026-46130", "cveTags": [], "metrics": {}, "published": "2026-05-28T10:16:28.570", "references": [{"url": "https://git.kernel.org/stable/c/3d1b4e2d8ac0a1a1390a117f61ce0ca1c47e3bcb", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/430a05cb926f6bdf53e81460a2c3a553257f3f61", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Awaiting Analysis", "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm-verity-fec: fix reading parity bytes split across blocks (take 3)\n\nfec_decode_bufs() assumes that the parity bytes of the first RS codeword\nit decodes are never split across parity blocks.\n\nThis assumption is false. Consider v->fec->block_size == 4096 &&\nv->fec->roots == 17 && fio->nbufs == 1, for example. In that case, each\ncall to fec_decode_bufs() consumes v->fec->roots * (fio->nbufs <<\nDM_VERITY_FEC_BUF_RS_BITS) = 272 parity bytes.\n\nConsidering that the parity data for each message block starts on a\nblock boundary, the byte alignment in the parity data will iterate\nthrough 272*i mod 4096 until the 3 parity blocks have been consumed. On\nthe 16th call (i=15), the alignment will be 4080 bytes into the first\nblock. Only 16 bytes remain in that block, but 17 parity bytes will be\nneeded. The code reads out-of-bounds from the parity block buffer.\n\nFortunately this doesn't normally happen, since it can occur only for\ncertain non-default values of fec_roots *and* when the maximum number of\nbuffers couldn't be allocated due to low memory. For example with\nblock_size=4096 only the following cases are affected:\n\n fec_roots=17: nbufs in [1, 3, 5, 15]\n fec_roots=19: nbufs in [1, 229]\n fec_roots=21: nbufs in [1, 3, 5, 13, 15, 39, 65, 195]\n fec_roots=23: nbufs in [1, 89]\n\nRegardless, fix it by refactoring how the parity blocks are read."}], "lastModified": "2026-05-28T13:44:01.663", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}