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]

Message-ID: <20181218151258.38796e76@redhat.com>
Date:   Tue, 18 Dec 2018 15:12:58 +0100
From:   Stefano Brivio <sbrivio@...hat.com>
To:     Dmitry Vyukov <dvyukov@...gle.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

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

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

-- 
Stefano