In the Linux kernel, the following vulnerability has been resolved: udf: validate sparing table length as an entry count, not a byte count… (CVE-2026-64322)
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().
AI Analysis
Technical Summary
The Linux kernel's udf_load_sparable_map() function incorrectly validates the reallocationTableLen field as a byte count instead of the actual number of 8-byte sparingEntry elements. This causes the code to perform out-of-bounds memory reads and writes in udf_get_pblock_spar15(), udf_relocate_blocks(), and udf_update_tag(), potentially leading to memory corruption. The vulnerability is fixed by validating reallocationTableLen as an entry count using struct_size().
Potential Impact
This vulnerability can cause out-of-bounds memory reads and writes when processing specially crafted UDF filesystem images. Such memory corruption could lead to kernel crashes or potentially allow an attacker to execute arbitrary code with kernel privileges if exploited. However, no known exploits are reported in the wild at this time.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, avoid mounting untrusted UDF filesystem images to mitigate risk.
In the Linux kernel, the following vulnerability has been resolved: udf: validate sparing table length as an entry count, not a byte count… (CVE-2026-64322)
Description
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().
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel's udf_load_sparable_map() function incorrectly validates the reallocationTableLen field as a byte count instead of the actual number of 8-byte sparingEntry elements. This causes the code to perform out-of-bounds memory reads and writes in udf_get_pblock_spar15(), udf_relocate_blocks(), and udf_update_tag(), potentially leading to memory corruption. The vulnerability is fixed by validating reallocationTableLen as an entry count using struct_size().
Potential Impact
This vulnerability can cause out-of-bounds memory reads and writes when processing specially crafted UDF filesystem images. Such memory corruption could lead to kernel crashes or potentially allow an attacker to execute arbitrary code with kernel privileges if exploited. However, no known exploits are reported in the wild at this time.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, avoid mounting untrusted UDF filesystem images to mitigate risk.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-r2mg-8x37-x2q4
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64322"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a65420d9c2644c7f80856ab
Added to database: 07/25/2026, 23:09:01 UTC
Last enriched: 07/25/2026, 23:34:20 UTC
Last updated: 09/08/2026, 10:52:11 UTC
Views: 37
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.