diff options
| author | Karl Mehltretter <kmehltretter@gmail.com> | 2026-08-22 16:33:27 +0200 |
|---|---|---|
| committer | Andrew Morton <akpm@linux-foundation.org> | 2026-10-08 23:06:56 -0700 |
| commit | 2600b567553d5cc094c02e28aea809371fef6609 (patch) | |
| tree | ab132fa81f9a513e0472880963001f827b16e455 /tools/lib/python/kdoc | |
| parent | 463dcad631f54ff2a830492b9f327a3a2db8c87e (diff) | |
| download | linux-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')
0 files changed, 0 insertions, 0 deletions
