GHSA-6HVC-RWFC-MP4J
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-05-28 12:30In 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.
{
"affected": [],
"aliases": [
"CVE-2026-46130"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:28Z",
"severity": null
},
"details": "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-\u003efec-\u003eblock_size == 4096 \u0026\u0026\nv-\u003efec-\u003eroots == 17 \u0026\u0026 fio-\u003enbufs == 1, for example. In that case, each\ncall to fec_decode_bufs() consumes v-\u003efec-\u003eroots * (fio-\u003enbufs \u003c\u003c\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\u0027t normally happen, since it can occur only for\ncertain non-default values of fec_roots *and* when the maximum number of\nbuffers couldn\u0027t 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.",
"id": "GHSA-6hvc-rwfc-mp4j",
"modified": "2026-05-28T12:30:30Z",
"published": "2026-05-28T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46130"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d1b4e2d8ac0a1a1390a117f61ce0ca1c47e3bcb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/430a05cb926f6bdf53e81460a2c3a553257f3f61"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.