CVE-2026-64322 in Linux
Summary
by MITRE • 07/25/2026
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().
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability in question affects the Linux kernel's Universal Disk Format implementation where a critical flaw exists in how the sparing table length is validated during UDF image processing. This issue stems from a fundamental misunderstanding of data structure interpretation within the udf_load_sparable_map() function that handles sparse allocation tables for UDF filesystems. The kernel incorrectly treats the reallocationTableLen field as a byte count rather than an entry count, creating a dangerous mismatch between validation logic and actual consumption patterns.
The technical flaw manifests when processing crafted UDF images where the reallocationTableLen field contains a value that passes initial validation checks but subsequently causes out-of-bounds memory access during table traversal operations. The validation condition sizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize incorrectly interprets the length parameter as bytes, while the actual processing code walks through the table as an array of 8-byte sparingEntry elements. This discrepancy creates a scenario where a table length of N bytes might pass validation yet causes the kernel to access memory locations that are approximately eight times larger than the allocated block size.
The operational impact of this vulnerability extends beyond simple memory corruption to include potential privilege escalation and system instability. When udf_get_pblock_spar15() processes the malformed sparing table, it performs out-of-bounds reads that could expose sensitive kernel memory contents or trigger denial-of-service conditions. Additionally, udf_relocate_blocks() feeds the same incorrect length value to udf_update_tag(), which then passes this data through crc_itu_t() function that reads far beyond block boundaries, and memmove() operations that result in out-of-bounds writes. This combination of read and write operations creates a comprehensive attack surface that could be exploited to manipulate kernel memory structures.
This vulnerability aligns with CWE-129 Input Validation and CWE-787 Out-of-bounds Write categories, representing a classic buffer over-read and over-write scenario common in filesystem implementations. The ATT&CK framework categorizes this issue under T1059 Command and Scripting Interpreter and T1566 Impairing Defenses, as it enables potential privilege escalation through kernel memory corruption. The flaw demonstrates poor input validation practices where the kernel fails to properly account for data structure element sizes during validation checks. Proper mitigation requires implementing struct_size() based validation that correctly interprets reallocationTableLen as an entry count rather than a byte count, ensuring that all memory accesses remain within allocated boundaries and preventing both read and write operations from exceeding valid memory regions.