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]
Date:   Thu, 17 Aug 2023 10:45:05 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Aleksandr Nogikh <nogikh@...gle.com>
Cc:     syzbot <syzbot+27eece6916b914a49ce7@...kaller.appspotmail.com>,
        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 Thu, Aug 17, 2023 at 04:28:33PM +0200, Aleksandr Nogikh wrote:
> The console log has the following line:
> 
> [   60.708717][ T5061] Kernel panic - not syncing: EXT4-fs (device
> loop0): panic forced after error
> 
> Can we consider a "panic forced after error" line to be a reliable
> indicator that syzbot must ignore the report?

Yes.  And the file system image that generated this bug should be
discarded, because otherwise successive mutations will generate a
large number of crashes that syzbot will then need to ignore, thus
consuming syzbot resources.

Alternatively, you can do the moral equivalent of "tune2fs -e continue
foo.img" on any mutated file system seed, which will clear the "panic
on error".

(The other alternative is "tune2fs -e remount-ro", but given syzbot's
desire to find kernel crashes, "tune2fs -e continue" is more likely
find ways in which the kernel will find itself into trouble.  Some
sysadmins will want to chose "remount-ro", however, since that is more
likely to limit file system damage once the file system is discovered
to be corrupted.)

					- Ted
					

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ