Re: [PATCH V7] squashfs: Add symlink size check in squash_read_inode

From: Lizhi Xu
Date: Mon Aug 05 2024 - 22:56:59 EST


On Mon, 5 Aug 2024 02:40:37 +0100, Al Viro wrote:
> > It is int overflow, not others.
>
> Excuse me, what?
>
> > Please see my V7 patch,
> > Link: https://lore.kernel.org/all/20240803074349.3599957-1-lizhi.xu@xxxxxxxxxxxxx/
>
> I have seen your patch. Integer overflow has nothing to do with
> the problem here.
No, the fix to this issue is due to the length overflow of int type caused
by the i_size of loff_t type (in the function squashfs_symlink_read_folio).
>
> Please, show me an unsigned int value N such that
>
> _Bool mismatch(unsigned int N)
> {
> u32 v32 = N;
> loff_t v64 = N;
>
> return (v32 > PAGE_SIZE) != (v64 > PAGE_SIZE);
> }
This always return 0, why are you asking this?
>
> would yield true if passed that value as an argument.
>
> Note that assignment of le32_to_cpu() result to inode->i_size
> does conversion from unsigned 32bit integer type to a signed 64bit
> integer type. Since the range of the former fits into the range of the
> latter, conversion preserves value. In other words, possible values
> of inode->i_size after such assignment are from 0 to (loff_t)0xfffffff
> and (inode->i_size > PAGE_SIZE) is true in exactly the same cases when
> (symlink_size > PAGE_SIZE) is true with your patch.
>
> Again, on all architectures inode->i_size is capable of representing
> all values in range 0..4G-1 (for rather obvious reasons - we want the
> kernel to be able to work with files larger than 4Gb). There is
> no wraparound of any kind on that assignment.
The type of loff_t is long long, so its values range is not 0..4G-1.

--
Lizhi