linux-kernel - Re: [PATCH V7] squashfs: Add symlink size check in squash_read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240806025609.1193466-1-lizhi.xu@windriver.com>
Date: Tue, 6 Aug 2024 10:56:09 +0800
From: Lizhi Xu <lizhi.xu@...driver.com>
To: <viro@...iv.linux.org.uk>
CC: <brauner@...nel.org>, <jack@...e.cz>, <linux-fsdevel@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <lizhi.xu@...driver.com>,
        <phillip@...ashfs.org.uk>, <squashfs-devel@...ts.sourceforge.net>,
        <syzbot+24ac24ff58dc5b0d26b9@...kaller.appspotmail.com>,
        <syzkaller-bugs@...glegroups.com>
Subject: Re: [PATCH V7] squashfs: Add symlink size check in squash_read_inode

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@windriver.com/
> 
> 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