{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.7-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003efec-\u003eblock_size == 4096 \u0026\u0026 v-\u003efec-\u003eroots == 17 \u0026\u0026 fio-\u003enbufs == 1, for example.  In that case, each call to fec_decode_bufs() consumes v-\u003efec-\u003eroots * (fio-\u003enbufs \u003c\u003c 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.",
  "id": "DEBIAN-CVE-2026-46130",
  "modified": "2026-09-14T16:47:43.425841790Z",
  "published": "2026-05-28T10:16:28.570Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-46130"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-46130"
  ]
}