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
