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.
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.
Update Linux/Linux to d47281b9a4472cfd73122393e79fbe76b651e46a if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scandm-verity-fec: fix reading parity bytes split across blocks (take 3) affects Linux/Linux (generic), Linux/Linux (generic). Severity is high. 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.
AI coding agents often install or upgrade packages automatically in generic. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=6df90c02bae468a3a6110bafbc659884d0c4966c <d47281b9a4472cfd73122393e79fbe76b651e46a || >=6df90c02bae468a3a6110bafbc659884d0c4966c <3d1b4e2d8ac0a1a1390a117f61ce0ca1c47e3bcb || >=6df90c02bae468a3a6110bafbc659884d0c4966c <430a05cb926f6bdf53e81460a2c3a553257f3f61 || 6bc6ee31113b05db605694491bdeb2b1730142f1 || 12caa73a28f0ae147ec0356b45091edf2462462b || fc8943886629e26de34867db302c74d465510826 || >=6.1.125 <6.2 || >=6.6.72 <6.7 || >=6.12.10 <6.13 | d47281b9a4472cfd73122393e79fbe76b651e46a, 3d1b4e2d8ac0a1a1390a117f61ce0ca1c47e3bcb, 430a05cb926f6bdf53e81460a2c3a553257f3f61, 6.2, 6.7, 6.13 |
| Linux/Linuxgeneric | 6.13 | Not reported |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by CVE List V5 (cvelist).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate Linux/Linux to d47281b9a4472cfd73122393e79fbe76b651e46a if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scandm-verity-fec: fix reading parity bytes split across blocks (take 3) affects Linux/Linux (generic), Linux/Linux (generic). Severity is high. 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.
AI coding agents often install or upgrade packages automatically in generic. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=6df90c02bae468a3a6110bafbc659884d0c4966c <d47281b9a4472cfd73122393e79fbe76b651e46a || >=6df90c02bae468a3a6110bafbc659884d0c4966c <3d1b4e2d8ac0a1a1390a117f61ce0ca1c47e3bcb || >=6df90c02bae468a3a6110bafbc659884d0c4966c <430a05cb926f6bdf53e81460a2c3a553257f3f61 || 6bc6ee31113b05db605694491bdeb2b1730142f1 || 12caa73a28f0ae147ec0356b45091edf2462462b || fc8943886629e26de34867db302c74d465510826 || >=6.1.125 <6.2 || >=6.6.72 <6.7 || >=6.12.10 <6.13 | d47281b9a4472cfd73122393e79fbe76b651e46a, 3d1b4e2d8ac0a1a1390a117f61ce0ca1c47e3bcb, 430a05cb926f6bdf53e81460a2c3a553257f3f61, 6.2, 6.7, 6.13 |
| Linux/Linuxgeneric | 6.13 | Not reported |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by CVE List V5 (cvelist).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard