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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230817142103.GA2247938@mit.edu>
Date:   Thu, 17 Aug 2023 10:21:03 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     syzbot <syzbot+27eece6916b914a49ce7@...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?] kernel panic: EXT4-fs (device loop0): panic
 forced after error (3)

On Wed, Aug 16, 2023 at 03:48:49PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    ae545c3283dc Merge tag 'gpio-fixes-for-v6.5-rc6' of git://..
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=13e5d553a80000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=171b698bc2e613cf
> dashboard link: https://syzkaller.appspot.com/bug?extid=27eece6916b914a49ce7
> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13433207a80000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=109cd837a80000
> 
> EXT4-fs error (device loop0): ext4_validate_block_bitmap:430: comm syz-executor211: bg 0: block 46: invalid block bitmap
> Kernel panic - not syncing: EXT4-fs (device loop0): panic forced after error

#syz invalid

This is fundamentally a syzbot bug.  The file system is horrifically
corrupted, *and* the superblock has the "panic on error" (aka "panic
onfile system corruption") bit set.

This can be desireable because in a failover situation, if the file
system is found to be corrupted, you *want* the primary server to
fail, and let the secondary server to take over.  This is a technique
which is decades old.

So this is Working As Intended, and is a classic example of (a) if you
are root, you can force the file system to crash, and (b) a classic
example of syzbot noise.  (Five minutes of my life that I'm never
getting back.  :-)

						- Ted

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ