Re: [PATCH v2] Squashfs: check block offset is not negative

On 06/08/2026 02:48, Andrew Morton wrote:
> 
> (cc sashiko@, I trust that's OK)

If it gets Sashiko to fix their problem then no objection.

> 
> On Wed, 5 Aug 2026 23:29:27 +0100 Phillip Lougher <[email protected]> wrote:
> 
>>
>>
>> On 05/08/2026 19:15, Andrew Morton wrote:
>>> On Wed,  5 Aug 2026 18:59:00 +0100 Phillip Lougher <[email protected]> wrote:
>>>
>>>> If a negative offset is read off disk (for example the offset into the
>>>> decompressed fragment block), this will cause squashfs_copy_data() to
>>>> perform an out of bounds access.
>>>>
>>>> Fix by checking if offset is negative, and returning 0.  This matches
>>>> existing behaviour where an offset beyond the block returns 0 bytes
>>>> copied.
>>>>
>>>> To trigger this out of bounds access requires a crafted Squashfs
>>>> filesystem and CAP_SYS_ADMIN to mount it.  Unprivileged users will not
>>>> be able to mount such a filesystem, but once mounted, an unprivileged
>>>> user can trigger the out of bounds access by reading the crafted file
>>>> with the negative offset.
>>>
>>> AI review thinks we might have an information leak in there:
>>> 	https://sashiko.dev/#/patchset/[email protected]
>>
>> Having done some more research, it looks like the AI is using an OLD kernel version
>> dating back to before 2018-08-01.
> 
> Thanks for looking into this.
> 
> I'd be surprised if this was the case, but what would I know?  Perhaps
> Sashiko trained itself on a seven year old kernel?

The solution to the mystery is to look at the Sashiko output, to
see where they got the kernel.

*********************
Selected:
squashfs-next/HEAD / 62421645
*********************

So the kernel they used is my squashfs-next tree.

There are three problems with that.

1. I have not updated the squashfs-next tree in at
    least twelve years (2014 would have been the latest).

2. I lost access to git.kernel.org in about 2015.

3. Having had a look on git.kernel.org, the squashfs-next tree doesn't
    seem to exist anymore anyway (purged due to disuse?)

So the fix here for Sashiko is to use the latest kernel tree, and not an
ancient squashfs-next tree which doesn't exist anymore.

Phillip