summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc/parse_data_structs.py
diff options
context:
space:
mode:
authorKarl Mehltretter <kmehltretter@gmail.com>2026-08-22 16:33:27 +0200
committerAndrew Morton <akpm@linux-foundation.org>2026-10-08 23:06:56 -0700
commit2600b567553d5cc094c02e28aea809371fef6609 (patch)
treeab132fa81f9a513e0472880963001f827b16e455 /tools/lib/python/kdoc/parse_data_structs.py
parent463dcad631f54ff2a830492b9f327a3a2db8c87e (diff)
downloadlinux-next-2600b567553d5cc094c02e28aea809371fef6609.tar.gz
linux-next-2600b567553d5cc094c02e28aea809371fef6609.zip
squashfs: fix fragment index table sizing overflow on 32-bit
Patch series "squashfs: harden fragment index table sizing". Two integer overflows undermine fragment index table handling. One is in the original fragment sizing macros. The other is in a bounds check added by commit 1cac63cc9b2f ("Squashfs: add sanity checks to fragment reading at mount time"). Patch 1: the fragment byte count wraps on 32-bit, so the index table is allocated too small and squashfs_frag_lookup() reads out of bounds. A crafted image triggers a KASAN out-of-bounds read on a 32-bit build. With the fix the same image fails cleanly at mount. Patch 2: the check that the table fits before the next one adds two u64 values controlled by the filesystem image and can wrap. This patch (of 2): SQUASHFS_FRAGMENT_BYTES() multiplies the on-disk fragment count (an unsigned int) by sizeof(struct squashfs_fragment_entry), a size_t. On a 32-bit kernel that product is 32-bit and can wrap. squashfs_read_fragment_index_table() sizes the fragment index table from it, but squashfs_frag_lookup() bounds the fragment number against msblk->fragments, the unwrapped superblock value. The two disagree: an image declaring 0x10000001 fragments wraps the product to 16, so a single index entry is allocated, yet the lookup still accepts fragment 0x0fffffff: if (fragment >= msblk->fragments) return -EIO; block = SQUASHFS_FRAGMENT_INDEX(fragment); ... start_block = le64_to_cpu(msblk->fragment_index[block]); block is then 524287 and the read lands ~4MB past an 8-byte allocation. On a 32-bit build KASAN catches it when the crafted image is mounted and the file is stat'd. Cast to u64 in the macro so the multiplication is 64-bit on all targets. After conversion to index-table entries, SQUASHFS_FRAGMENT_INDEX_BYTES() is at most 64 MiB for any u32 count, so it fits both the unsigned int local and the int argument it feeds. 64-bit builds are unchanged. Link: https://lore.kernel.org/20260822143328.68867-1-kmehltretter@gmail.com Link: https://lore.kernel.org/20260822143328.68867-2-kmehltretter@gmail.com Fixes: ffae2cd73a9e ("Squashfs: header files") Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Assisted-by: Claude:claude-opus-5 Cc: Phillip Lougher <phillip@squashfs.org.uk> Cc: <stable@vger.kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc/parse_data_structs.py')
0 files changed, 0 insertions, 0 deletions