[PATCH 0/2] squashfs: harden fragment index table sizing

[PATCH 0/2] squashfs: harden fragment index table sizing

[Karl Mehltretter]

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.

Built W=1 with gcc (x86_64, i386) and clang (x86_64).  Strict
checkpatch is clean.

Karl Mehltretter (2):
  squashfs: fix fragment index table sizing overflow on 32-bit
  squashfs: make the fragment index table bounds check overflow-safe

 fs/squashfs/fragment.c    | 6 ++++--
 fs/squashfs/squashfs_fs.h | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

-- 
2.53.0

[PATCH 1/2] squashfs: fix fragment index table sizing overflow on 32-bit

[Karl Mehltretter]

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.

Fixes: ffae2cd73a9e ("Squashfs: header files")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
 fs/squashfs/squashfs_fs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/squashfs/squashfs_fs.h b/fs/squashfs/squashfs_fs.h
index a955d9369749f..93436c7d80c97 100644
--- a/fs/squashfs/squashfs_fs.h
+++ b/fs/squashfs/squashfs_fs.h
@@ -136,7 +136,7 @@ static inline int squashfs_block_size(__le32 raw)
 
 /* fragment and fragment table defines */
 #define SQUASHFS_FRAGMENT_BYTES(A)	\
-				((A) * sizeof(struct squashfs_fragment_entry))
+			((u64)(A) * sizeof(struct squashfs_fragment_entry))
 
 #define SQUASHFS_FRAGMENT_INDEX(A)	(SQUASHFS_FRAGMENT_BYTES(A) / \
 					SQUASHFS_METADATA_SIZE)
-- 
2.53.0

[PATCH 2/2] squashfs: make the fragment index table bounds check overflow-safe

[Karl Mehltretter]

squashfs_read_fragment_index_table() checks that the table fits before
the next one with:

	if (fragment_table_start + length > next_table)
		return ERR_PTR(-EINVAL);

fragment_table_start comes from the superblock and is not validated
before this point. A start of 2^64 - length wraps the sum to zero, so
the check passes regardless of next_table and fails to reject the
invalid table ordering.

length then reaches kmalloc() through squashfs_read_table(). A
fragment count of 0xffffffff asks for 64MB, order 14. GFP_KERNEL does
not include __GFP_NOWARN, so the page allocator warns before the mount
fails with -ENOMEM. With panic_on_warn, the warning panics the kernel.

Compare the operands instead of adding them. id.c and export.c avoid
the same wrap with an exact-size check. Keep the inequality here because
a gap before the next table is still allowed.

Fixes: 1cac63cc9b2f ("Squashfs: add sanity checks to fragment reading at mount time")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
 fs/squashfs/fragment.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/squashfs/fragment.c b/fs/squashfs/fragment.c
index 49602b9a42e19..b46673d1077a0 100644
--- a/fs/squashfs/fragment.c
+++ b/fs/squashfs/fragment.c
@@ -69,9 +69,11 @@ __le64 *squashfs_read_fragment_index_table(struct super_block *sb,
 	/*
 	 * Sanity check, length bytes should not extend into the next table -
 	 * this check also traps instances where fragment_table_start is
-	 * incorrectly larger than the next table start
+	 * incorrectly larger than the next table start.  Both values are read
+	 * from the filesystem image, so compare without adding them.
 	 */
-	if (fragment_table_start + length > next_table)
+	if (fragment_table_start > next_table ||
+	    length > next_table - fragment_table_start)
 		return ERR_PTR(-EINVAL);
 
 	table = squashfs_read_table(sb, fragment_table_start, length);
-- 
2.53.0

Re: [PATCH 0/2] squashfs: harden fragment index table sizing

[Andrew Morton]

On Sat, 22 Aug 2026 16:33:26 +0200 Karl Mehltretter <kmehltretter@gmail.com> wrote:

> 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.
> 
> Built W=1 with gcc (x86_64, i386) and clang (x86_64).  Strict
> checkpatch is clean.

Thanks.

When fixing bugs, please always include a clear and succinct
description of the userspace-visible runtime effects of the bug. 
Especially when proposing a -stable backport.  It should be easy to add
this to Claude's prompts!

I expect that Claude could also generate reproducers for such issues. 
Although it may not be trivial in this case, as a corrupted fs image
will need to be created.  If you are able to generate the reproducers
then please document this in the changelogging in an appropriate
fashion.


Sashiko review of this series claims to have found a whole bunch of
similar issues which you may choose to address:

	https://sashiko.dev/#/patchset/20260822143328.68867-1-kmehltretter@gmail.com

I don't know how useful this report will be - the first part seems
wrong in lots of ways, as if Sashiko was using an ancient copy of the
code.  But the things it claims aren't there have been present since
2018.


Anyway, let me get these fixes queued for testing while we await
additional reviewer input.

Re: [PATCH 0/2] squashfs: harden fragment index table sizing

[Phillip Lougher]

> On 29/08/2026 00:37 BST Andrew Morton <akpm@linux-foundation.org> wrote:
> 
>  
> Sashiko review of this series claims to have found a whole bunch of
> similar issues which you may choose to address:
> 
> 	https://sashiko.dev/#/patchset/20260822143328.68867-1-kmehltretter@gmail.com
> 
> I don't know how useful this report will be - the first part seems
> wrong in lots of ways, as if Sashiko was using an ancient copy of the
> code.  But the things it claims aren't there have been present since
> 2018.
> 

I have been receiving a lot of AI generated issues similar to these on the
Squashfs-tools code and the Squashfs kernel code over the last month.

I have not been idle and ignoring them, and I have been spent the last
couple of weeks fixing them full-time in the Squashfs-tools code, and
the kernel code.

In the Squashfs-tools code I have reviewed about 20,000 lines of code so
far, and this has generated over 50 commits.  These commits I have
committed to the Squashfs-tools git-hub repository here

https://github.com/plougher/squashfs-tools

I am also most of the way through reviewing the Squashfs kernel code, it
is about 70% complete.  So far it has generated 12 patches, and there
will be more.  Obviously the kernel patches are queued up for a posting
next week.

So I am not asleep at the wheel here, I know about them and I am
addressing them.

Phillip

Re: [PATCH 0/2] squashfs: harden fragment index table sizing

[Andrew Morton]

On Sat, 29 Aug 2026 03:48:31 +0100 (BST) Phillip Lougher <phillip@squashfs.org.uk> wrote:

> 
> > On 29/08/2026 00:37 BST Andrew Morton <akpm@linux-foundation.org> wrote:
> > 
> >  
> > Sashiko review of this series claims to have found a whole bunch of
> > similar issues which you may choose to address:
> > 
> > 	https://sashiko.dev/#/patchset/20260822143328.68867-1-kmehltretter@gmail.com
> > 
> > I don't know how useful this report will be - the first part seems
> > wrong in lots of ways, as if Sashiko was using an ancient copy of the
> > code.  But the things it claims aren't there have been present since
> > 2018.
> > 
> 
> I have been receiving a lot of AI generated issues similar to these on the
> Squashfs-tools code and the Squashfs kernel code over the last month.
> 
> I have not been idle and ignoring them, and I have been spent the last
> couple of weeks fixing them full-time in the Squashfs-tools code, and
> the kernel code.
> 
> In the Squashfs-tools code I have reviewed about 20,000 lines of code so
> far, and this has generated over 50 commits.  These commits I have
> committed to the Squashfs-tools git-hub repository here
> 
> https://github.com/plougher/squashfs-tools
> 
> I am also most of the way through reviewing the Squashfs kernel code, it
> is about 70% complete.  So far it has generated 12 patches, and there
> will be more.  Obviously the kernel patches are queued up for a posting
> next week.

Cool, thanks for the diligence.  Lots of projects appear to be in the
same boat at present - hang in there!

> So I am not asleep at the wheel here, I know about them and I am
> addressing them.

I hope it didn't sound like I was implying such a thing!

For a patch series like this: it looks correct enough to me so my
approach is to push it out for external testing and to sit on it
indefinitely until I hear from Maintainer.