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_...

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().

Metrics

CVSS 3.1

7.8/10

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS Probability

0.16%

6.0th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
Linux	Linux	>= 1df2ae31c724e57be9d7ac00d78db8a5dabdd050, < eeb0f3e193f8e523d03e4c9e084f6b4875f50e8e; >= 1df2ae31c724e57be9d7ac00d78db8a5dabdd050, < 0a9b79a951cfd70a9d31ca01ae2d08a20bb730e9; >= 1df2ae31c724e57be9d7ac00d78db8a5dabdd050, < 2d726135099313958f8975532a2e15322ff150ce; >= 1df2ae31c724e57be9d7ac00d78db8a5dabdd050, < 7285276aa50d2839afb5957ffd491ad282dc8f72; >= 1df2ae31c724e57be9d7ac00d78db8a5dabdd050, < 2a219acb2ce674d99bbd1b7b35ed8c384dac7200; >= 1df2ae31c724e57be9d7ac00d78db8a5dabdd050, < 04f4599a9efb90992d072a814960edf0cd62805d; >= 1df2ae31c724e57be9d7ac00d78db8a5dabdd050, < 7f7774b9da0ef17b87bfa238cf966ad0b3376150; >= 1df2ae31c724e57be9d7ac00d78db8a5dabdd050, < 3ec997bd5508e9b25210b5bbec89031629cdb093; e240873cb4a9fd18de60a817100a96fe670d4359; 9ae30e324a96d0328a575329d7a95a09b3318601; b1c5701ad6b3e5d21d16f65475651cfaaa41e7aa; a9f1af04f086656246f30354fb4564ce3b08c4a0; 4836ee563d65bb492f907cbe267a5761b9693e4d; >= 2.6.32.60, < 2.6.33; >= 2.6.34.14, < 2.6.35; >= 3.0.37, < 3.1; >= 3.2.23, < 3.3; >= 3.4.5, < 3.5
Linux	Linux	3.5

References

Timeline

Published: Jul 25, 2026
Last Modified: Aug 11, 2026
Status: Awaiting Analysis

Frequently Asked Questions

What is 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().

How severe is CVE-2026-64322?

CVE-2026-64322 has a CVSS score of 7.8/10 (HIGH severity). The EPSS model estimates a 0.16% probability of exploitation in the next 30 days.

How do I fix CVE-2026-64322?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →