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().
CVSS
7.8 HIGH (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
from 1df2ae31c724e57be9d7ac00d78db8a5dabdd050 before eeb0f3e193f8e523d03e4c9e084f6b4875f50e8e; 1df2ae31c724e57be9d7ac00d78db8a5dabdd050 builds before 0a9b79a951cfd70a9d31ca01ae2d08a20bb730e9; from 1df2ae31c724e57be9d7ac00d78db8a5dabdd050 before 2d726135099313958f8975532a2e15322ff150ce; from 1df2ae31c724e57be9d7ac00d78db8a5dabdd050 before 7285276aa50d2839afb5957ffd491ad282dc8f72; from 1df2ae31c724e57be9d7ac00d78db8a5dabdd050 before 2a219acb2ce674d99bbd1b7b35ed8c384dac7200; from 1df2ae31c724e57be9d7ac00d78db8a5dabdd050 before 04f4599a9efb90992d072a814960edf0cd62805d; from 1df2ae31c724e57be9d7ac00d78db8a5dabdd050 before 7f7774b9da0ef17b87bfa238cf966ad0b3376150; from 1df2ae31c724e57be9d7ac00d78db8a5dabdd050 before 3ec997bd5508e9b25210b5bbec89031629cdb093; and 10 more ranges
from 2.6.32.60 before 2.6.33; from 2.6.34.14 before 2.6.35; from 3.0.37 before 3.1; from 3.2.23 before 3.3; from 3.4.5 before 3.5; from 3.5.1 before 5.10.261; from 5.11 before 5.15.212; from 5.16 before 6.1.178; and 8 more ranges
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.
Printed from infosecsignals.com. Every record links back to the agency that published it.
Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.