CVE-2026-64322: udf: validate sparing table length as an entry count, not a byte count
In the Linux kernel, the following vulnerability has been resolved:
udf: validate sparing table length as an entry count, not a byte count
udfloadsparablemap() accepts a sparing table when
sizeof(st) + le16tocpu(st->reallocationTableLen) > sb->sblocksize
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 < le16tocpu(st->reallocationTableLen); i++) { struct sparingEntry entry = &st->mapEntry[i]; ... entry->origLocation ... }
in udfgetpblockspar15() and udfrelocateblocks(). 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 udfgetpblockspar15(); udfrelocateblocks() additionally feeds the same length to udfupdatetag(), whose crcitut() 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 structsize().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.145.2-1 - Compensating control
In the UDF sparing-table handling, validate reallocationTableLen as an entry count: ensure sizeof(*st) + le16_to_cpu(st->reallocationTableLen) * sizeof(struct sparingEntry) does not exceed sb->s_blocksize before processing the table in udf_get_pblock_spar15() and udf_relocate_blocks().
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems running an affected Linux kernel or the listed Microsoft azl3 kernel are exposed when they process a crafted UDF filesystem image containing a malformed sparing table.
What access does an attacker need to exploit it?
The CVSS vector indicates local access and low privileges are required, with no user interaction. Exploitation depends on getting the vulnerable kernel to process the crafted UDF image.
What can happen if the issue is exploited?
Malformed sparing-table lengths can cause out-of-bounds reads during physical-block lookup and relocation. The relocation path can also perform an out-of-bounds write through the sparing-table entry array, affecting confidentiality, integrity, and availability.
What should be done if patching cannot happen immediately?
Avoid processing untrusted or crafted UDF filesystem images until the available patch can be applied.