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

[Andrew Morton <akpm@linux-foundation.org>]

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.