FKIE_CVE-2026-46130

Vulnerability from fkie_nvd - Published: 2026-05-28 10:16 - Updated: 2026-05-28 13:44
Severity
Summary
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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/3d1b4e2d8ac0a1a1390a117f61ce0ca1c47e3bcb
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/430a05cb926f6bdf53e81460a2c3a553257f3f61
Impacted products
Vendor Product Version
To clipboard 

{
  "cveTags": [],
  "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-\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": "CVE-2026-46130",
  "lastModified": "2026-05-28T13:44:01.663",
  "metrics": {},
  "published": "2026-05-28T10:16:28.570",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/3d1b4e2d8ac0a1a1390a117f61ce0ca1c47e3bcb"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/430a05cb926f6bdf53e81460a2c3a553257f3f61"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.


Detection rules are retrieved from Rulezet.