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

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] [day] [month] [year] [list]

Date:   Wed, 28 Jun 2023 23:35:09 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     syzbot <syzbot+f4cf49c6365d87eb8e0e@...kaller.appspotmail.com>
Cc:     adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        llvm@...ts.linux.dev, nathan@...nel.org, ndesaulniers@...gle.com,
        syzkaller-bugs@...glegroups.com, trix@...hat.com
Subject: Re: [syzbot] [ext4?] UBSAN: shift-out-of-bounds in
 ext4_handle_clustersize

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