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

Message-ID: <CANp29Y6JE-HyYL6XZfBy8QvE2CwLHw-HdtVsYxAGMhfy9qT=RQ@mail.gmail.com>
Date:   Fri, 18 Aug 2023 18:46:57 +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)

On Fri, Aug 18, 2023 at 1:43 PM Aleksandr Nogikh <nogikh@...gle.com> wrote:
>
> 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.

Ah, it's a bit trickier -- the syz_mount_image() code is fine. The
reproducer first mounts an ext4 image via syz_mount_image(), which
appends "errors=continue" to the options and it doesn't lead to the
panic. But then the reproducer does a direct mount() call for the loop
device previously created in syz_mount_image(), this time _without_
mount options.

I've sent https://github.com/google/syzkaller/pull/4143 to sanitize
plain mount() calls.

>
>
> 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
> >