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

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.

> 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

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.