linux-ext4 - Re: [syzbot] [ext4?] possible deadlock in ext4

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: <20230515005321.GB1903212@mit.edu>
Date:   Sun, 14 May 2023 20:53:21 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     "Michael S. Tsirkin" <mst@...hat.com>
Cc:     syzbot <syzbot+cbb68193bdb95af4340a@...kaller.appspotmail.com>,
        adilger.kernel@...ger.ca, elic@...dia.com, jasowang@...hat.com,
        linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, parav@...dia.com,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [ext4?] possible deadlock in ext4_setattr

On Sun, May 14, 2023 at 04:39:36PM -0400, Michael S. Tsirkin wrote:
> On Sun, May 14, 2023 at 12:24:32PM -0700, syzbot wrote:
> > syzbot has bisected this issue to:
> > 
> > commit a3c06ae158dd6fa8336157c31d9234689d068d02
> > Author: Parav Pandit <parav@...dia.com>
> > Date:   Tue Jan 5 10:32:03 2021 +0000
> > 
> >     vdpa_sim_net: Add support for user supported devices
> > 
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> 
> I don't see how this can be related, I don't think the test setup uses
> vdpa sim at all.

Yeah, it's totally bogus.  You can see it by looking at the bisection
log[1].

[1] https://syzkaller.appspot.com/text?tag=Log&x=16e372c6280000

The initial bisection logs make it clear that it is *trivially* easy
to reproduce, and that the failure signature is:

crashed: possible deadlock in {ext4_xattr_set_handle,ext4_setattr,ext4_xattr_set_handle}

However, somewhere in the bisection, we start seeing this:

run #0: boot failed: WARNING in kvm_wait
run #1: boot failed: WARNING in kvm_wait
run #2: OK
run #3: OK
run #4: OK
run #5: OK
run #6: OK
run #7: OK
run #8: OK
run #9: OK

This is a completely different failure signature, and the "WARNING in
kvm_wait" should be ignored, and this should be considered a "git
bisect good".  However, the syzkaller bisection doesn't understand
this, and so it gets sent down the primrose path.  :-(

Unfortunately, there isn't a good way to tell the syzkaller bisection,
"go home, your drunk", and to tell it to try again, perhaps with a
human-supplied discriminator of what should be considered a valid
failure signature.

In the ideal world, a human should be able to give it a setup set of
bisection "good" and "bad" commits, along with a regexp for what a
failure should look like, and perhaps with a hint of how many tries it
should use before assuming that a bisection result is "good", and to
teach it to assume that the bisection has "bad" after seeing a single
failure signature.

If the above is too much to ask, in the slightly-less-ideal world,
there would be a way to give "#syz test" a count argument, so we could
have syzkaller try N times, for when we need to do a manual bisection
using "#syz test"....

						- Ted