linux-kernel - Re: [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic forced after error (3)

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: <CANp29Y4HGnp6LJ7jw2hrXNFd7S4+MKfjdpjOGZALUuGK1L3wPA@mail.gmail.com>
Date:   Fri, 18 Aug 2023 13:43:45 +0200
From:   Aleksandr Nogikh <nogikh@...gle.com>
To:     "Theodore Ts'o" <tytso@....edu>
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)

I've taken a closer look at the issue.

Documentation/filesystems/ext4.txt says that the "errors=" mount
parameter "override the errors behavior specified in the superblock".
So syzbot can prevent it by passing "errors=continue" as a mount
argument and there's no need to filter out such reports.

Syzkaller actually already does that in the C reproducer. It just
seems that this time the tool has mutated the mount options so much
that the simple patching no longer worked (most likely because of \0
characters in between). I'll update the syz_mount_image() code.


On Thu, Aug 17, 2023 at 4:45 PM Theodore Ts'o <tytso@....edu> wrote:
>
> 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
>