Linux Kernel up to 7.0.6 dm-verity-fec fec_decode_bufs out-of-bounds

Summaryinfo

A vulnerability was found in Linux Kernel up to 7.0.6. It has been rated as critical. The affected element is the function fec_decode_bufs of the component dm-verity-fec. This manipulation causes out-of-bounds. This vulnerability is registered as CVE-2026-46130. No exploit is available. Upgrading the affected component is advised.

Detailsinfo

A vulnerability classified as problematic was found in Linux Kernel up to 7.0.6. Affected by this vulnerability is the function fec_decode_bufs of the component dm-verity-fec. The manipulation with an unknown input leads to a out-of-bounds vulnerability. The CWE definition for the vulnerability is CWE-125. The product reads data past the end, or before the beginning, of the intended buffer. As an impact it is known to affect confidentiality. The summary by CVE is:

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.

The advisory is shared at git.kernel.org. This vulnerability is known as CVE-2026-46130 since 05/13/2026. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 06/25/2026).

Upgrading to version 7.0.7 or 7.1-rc1 eliminates this vulnerability. Applying the patch 3d1b4e2d8ac0a1a1390a117f61ce0ca1c47e3bcb/430a05cb926f6bdf53e81460a2c3a553257f3f61 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 7.0.0
• 7.0.1
• 7.0.2
• 7.0.3
• 7.0.4
• 7.0.5
• 7.0.6

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion