linux-kernel - Re: WARNING in __rcu_read

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:   Tue, 18 Dec 2018 17:05:41 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Stefano Brivio <sbrivio@...hat.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        "Paul E. McKenney" <paulmck@...ux.ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Josh Triplett <josh@...htriplett.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        netdev <netdev@...r.kernel.org>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Xin Long <lucien.xin@...il.com>
Subject: Re: WARNING in __rcu_read_unlock

On Tue, Dec 18, 2018 at 3:13 PM Stefano Brivio <sbrivio@...hat.com> wrote:
>
> [Dropping syzbot from Cc:]
>
> On Tue, 18 Dec 2018 14:26:00 +0100
> Dmitry Vyukov <dvyukov@...gle.com> wrote:
>
> > On Tue, Dec 18, 2018 at 1:40 PM Stefano Brivio <sbrivio@...hat.com>
> > wrote:
> >
> > > Maybe it would be nice to have a semi-automated way to isolate and
> > > describe/name specific conditions found by syzbot via fuzzing and
> > > turn those into tests that are then repeated periodically. I'm not
> > > sure how that would look like, but I think it's still more
> > > maintainable than a pile of C reproducers with forged packets in
> > > selftests/net.
> >
> > It would be nice to do something like this. Filed
> > https://github.com/google/syzkaller/issues/884
> > However, there are few open questions that I am not sure how to
> > resolve yet...
>
> I don't have a github account, so let me comment on your questions here:
>
> > 1. How to effectively fetch so many repros from datastore without
> > hitting timeouts? We probably need to limit this to 1 repro per bug,
> > but still that's many repros.
>
> I guess this would be less of a problem if reproducers are selected
> based on input from developers, instead of just taking all the
> reproducers. E.g. one could answer a report with something like:
>
>         #syz regression-test: <name>
>         <description>
>
> in this case I would have answered:
>
>         #syz regression-test: icmp-udp-in-gue-recursion
>         ICMP exceptions on UDP direct encapsulation in GUE
>
> and something could be automatically appended to the test name,
> perhaps e-mail and date. It would also be nice to be able to undo
> this and delete a regression test.
>
> > 2. Do we need some sorting based on namespace? E.g. stable releases
> > may not include fixes for bugs fixed in upstream, then we will just
> > crash lots of kernels in vain.
>
> Same here, I guess developer input might help, but I'm not sure how to
> formalise this.


I hope we can solve these technical problems without imposing more
work onto humans. And just run all repros.
Besides the fact that it's just not good to ask people to do what
machines can do, _very_ few people will use these new tags.
Potentially we will have just this repro marked by you :)


> > 3. syzkaller repros depend on exact syzkaller revision, new syzkaller
> > won't be able to use old repros. Using C repros is much harder and
> > they are not present for all bugs. Not sure what to do here.
>
> Would it make a difference if you could use the "syz" reproducers and
> translate them to C reproducer only once needed?

That's the problem. Once we need them we will need to build and copy
to the target machine the exact syzkaller revision used to produce
that repro. So if we will test 10K repros, we will need 10K builds and
binaries copied.