GHSA-R2MG-8X37-X2Q4

Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-07-27 06:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

udf: validate sparing table length as an entry count, not a byte count

udf_load_sparable_map() accepts a sparing table when

sizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize

is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements:

for (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) {
    struct sparingEntry *entry = &st->mapEntry[i];
    ... entry->origLocation ...
}

in udf_get_pblock_spar15() and udf_relocate_blocks(). A reallocationTableLen of N therefore passes the check whenever sizeof(st) + N <= blocksize, yet the consumers index sizeof(st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block. On a crafted UDF image this is an out-of-bounds read in udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the same length to udf_update_tag(), whose crc_itu_t() reads far past the block, and its memmove() through st->mapEntry[] is an out-of-bounds write.

Validate reallocationTableLen as the entry count it is, with struct_size().

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-64322"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-25T10:17:13Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nudf: validate sparing table length as an entry count, not a byte count\n\nudf_load_sparable_map() accepts a sparing table when\n\n\tsizeof(*st) + le16_to_cpu(st-\u003ereallocationTableLen) \u003e sb-\u003es_blocksize\n\nis false, i.e. it treats reallocationTableLen as a number of BYTES that\nmust fit in the block.  But the table is walked as an array of 8-byte\nsparingEntry elements:\n\n\tfor (i = 0; i \u003c le16_to_cpu(st-\u003ereallocationTableLen); i++) {\n\t\tstruct sparingEntry *entry = \u0026st-\u003emapEntry[i];\n\t\t... entry-\u003eorigLocation ...\n\t}\n\nin udf_get_pblock_spar15() and udf_relocate_blocks().  A\nreallocationTableLen of N therefore passes the check whenever\nsizeof(*st) + N \u003c= blocksize, yet the consumers index\nsizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the\nblock.  On a crafted UDF image this is an out-of-bounds read in\nudf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the\nsame length to udf_update_tag(), whose crc_itu_t() reads far past the\nblock, and its memmove() through st-\u003emapEntry[] is an out-of-bounds\nwrite.\n\nValidate reallocationTableLen as the entry count it is, with\nstruct_size().",
  "id": "GHSA-r2mg-8x37-x2q4",
  "modified": "2026-07-27T06:30:33Z",
  "published": "2026-07-25T12:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64322"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/04f4599a9efb90992d072a814960edf0cd62805d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0a9b79a951cfd70a9d31ca01ae2d08a20bb730e9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a219acb2ce674d99bbd1b7b35ed8c384dac7200"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2d726135099313958f8975532a2e15322ff150ce"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3ec997bd5508e9b25210b5bbec89031629cdb093"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7285276aa50d2839afb5957ffd491ad282dc8f72"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7f7774b9da0ef17b87bfa238cf966ad0b3376150"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/eeb0f3e193f8e523d03e4c9e084f6b4875f50e8e"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}



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.