CVE-2026-90203: Squashfs: check block offset is not negative
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: check block offset is not negative
If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfscopydata() 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 CAPSYSADMIN 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.
Affected Software
Event History
Frequently Asked Questions
Who can introduce the malicious filesystem image?
Mounting the crafted Squashfs filesystem requires CAP_SYS_ADMIN, so an unprivileged user cannot mount it directly. A privileged user or service that mounts attacker-controlled Squashfs images is the relevant exposure point.
Can an unprivileged user trigger the flaw after the filesystem is mounted?
Yes. Once a crafted Squashfs filesystem has been mounted, an unprivileged user can trigger the out-of-bounds access by reading the crafted file containing the negative offset.
What condition in the filesystem image causes the issue?
The issue occurs when an on-disk offset, such as an offset into a decompressed fragment block, is negative. The vulnerable path passes that offset to squashfs_copy_data(), resulting in an out-of-bounds access.
What behavior does the fix introduce for invalid offsets?
The fix checks for a negative offset and returns zero bytes copied. This aligns negative-offset handling with the existing behavior for offsets beyond the block.