Re: [syzbot] [ext4?] UBSAN: shift-out-of-bounds in ext4_handle_clustersize

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 22, 2023 at 05:01:44AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    1b29d271614a Merge tag 'staging-6.4-rc7' of git://git.kern..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15fefd03280000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=7ff8f87c7ab0e04e
> dashboard link: https://syzkaller.appspot.com/bug?extid=f4cf49c6365d87eb8e0e
> compiler:       Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
> 
> Unfortunately, I don't have any reproducer for this issue yet.

> UBSAN: shift-out-of-bounds in fs/ext4/super.c:4401:27
> shift exponent 374 is too large for 32-bit type 'int'

fs/ext4/super.c:4401 is:

	clustersize = BLOCK_SIZE << le32_to_cpu(es->s_log_cluster_size);

... however earlier, in ext4_load_super() we check to make sure that
(es->s_log_cluster_size) is no more than 20 (EXT4_MAX_BLOCK_LOG_SIZE -
EXT4_MIN_BLOCK_LOG_SIZE).

So it's likely this is either a while pointer corrupting the
superblock after we've checked the value, but before we try to use it
later.... or this is another "some thread is actively writing to the
block device while we are in the process of mounting the file system".

Since it's only occurred once, and we have no reproducer, it's
impossible to say, but we'll just ignore this for now.

	      	       	     	  	      - Ted



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux