Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 18 Dec 2018 06:02:58 -0800
From:   "Paul E. McKenney" <paulmck@linux.ibm.com>
To:     Dmitry Vyukov <dvyukov@google.com>
Cc:     Stefano Brivio <sbrivio@redhat.com>,
        Eric Dumazet <eric.dumazet@gmail.com>,
        Arjan van de Ven <arjan@linux.intel.com>,
        syzbot <syzbot+43f6755d1c2e62743468@syzkaller.appspotmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Josh Triplett <josh@joshtriplett.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
        netdev <netdev@vger.kernel.org>,
        Cong Wang <xiyou.wangcong@gmail.com>,
        Xin Long <lucien.xin@gmail.com>
Subject: Re: WARNING in __rcu_read_unlock
Reply-To: paulmck@linux.ibm.com
References: <20181217112916.GG4170@linux.ibm.com>
 <1583d5fc-34bf-3a81-363d-01a1085a7363@linux.intel.com>
 <CACT4Y+aKn4XsGVgt3ELGnnJcg6H-m+dSdV018dLvJhrpshycWA@mail.gmail.com>
 <20641819-e4fb-f3bd-34c8-c68106cccd0e@gmail.com>
 <20181217162421.6d636ee5@redhat.com>
 <CACT4Y+YXFrnQh9h1KQf8=NcHugmxTj+d7AQdGCvRX_xsHwr1qA@mail.gmail.com>
 <20181218001828.49cea463@redhat.com>
 <CACT4Y+ZFpO26Tgqpi+Jies9XOiiCgAdp2DV0z_54hCNTqkJsiw@mail.gmail.com>
 <20181218134024.45d2d5e3@redhat.com>
 <CACT4Y+az3--Y2f0OKSbF0kxwckdkKSASVog=XkX=+cXCt5r3ew@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACT4Y+az3--Y2f0OKSbF0kxwckdkKSASVog=XkX=+cXCt5r3ew@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-Id: <20181218140258.GQ4170@linux.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Dec 18, 2018 at 02:26:00PM +0100, Dmitry Vyukov wrote:
> On Tue, Dec 18, 2018 at 1:40 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> >
> > On Tue, 18 Dec 2018 09:49:17 +0100
> > Dmitry Vyukov <dvyukov@google.com> wrote:
> >
> > > On Tue, Dec 18, 2018 at 12:18 AM Stefano Brivio <sbrivio@redhat.com> wrote:
> > > >
> > > > On Mon, 17 Dec 2018 16:53:36 +0100
> > > > Dmitry Vyukov <dvyukov@google.com> wrote:
> > > >
> > > > > On Mon, Dec 17, 2018 at 4:24 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> > > > > >
> > > > > > On Mon, 17 Dec 2018 06:57:35 -0800
> > > > > > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > > > > >
> > > > > > > Might be cause by commit b8a51b38e4d4dec3e379d52c0fe1a66827f7cf1e
> > > > > > > fou, fou6: ICMP error handlers for FoU and GUE
> > > > > >
> > > > > > This:
> > > > > >
> > > > > > diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
> > > > > > index 0d0ad19ecb87..20a6de26d146 100644
> > > > > > --- a/net/ipv4/fou.c
> > > > > > +++ b/net/ipv4/fou.c
> > > > > > @@ -1008,6 +1008,9 @@ static int gue_err_proto_handler(int proto, struct sk_buff *skb, u32 info)
> > > > > >  {
> > > > > >         const struct net_protocol *ipprot = rcu_dereference(inet_protos[proto]);
> > > > > >
> > > > > > +       if (ipprot == IPPROTO_UDP)
> > > > > > +               return -EINVAL;
> > > > > > +
> > > > > >         if (ipprot && ipprot->err_handler) {
> > > > > >                 if (!ipprot->err_handler(skb, info))
> > > > > >                         return 0;
> > > > > >
> > > > > > should fix the issue, but I still have to run tests and make sure we
> > > > > > don't hit similar cases.
> > > > >
> > > > > Please don't forget to add a regression test for it too ;)
> > > >
> > > > Where would you suggest to add this? The only selftest that goes
> > >
> > > I dunno. But there must be some place for such tests, right?
> >
> > Not as far as I know. The selftests checking this path, by design, only
> > use supported configurations, they don't forge packets.
> >
> > 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...
> 
> 
> > Eric, Cong, Xin, as you also recently fixed a nice deal of similar cases
> > reported by syzbot, what do you think? Did you ever feel the need to
> > turn a syzbot reproducer into a regression test case?
> >
> > > > through this path currently is net/pmtu.sh, but as configuration of an
> > > > actual UDP-in-GUE tunnel is currently not supported, I would really
> > > > need to forge that specific packet, so that doesn't seem to be a good
> > > > fit.
> > > >
> > > > Won't syzbot add this to some list of reproducers that are checked in
> > > > the future?
> > >
> > > It won't. Also fuzzing is complementary to testing, not a replacement:
> >
> > Indeed, but that doesn't mean we need to limit the potential of fuzzing
> > because "it's not testing". It can be used to check for regressions,
> > too, especially in these cases.
> >
> > > https://twitter.com/dvyukov/status/1074719682962358272
> >
> > Now, I'm extremely thankful for the work you're doing and especially
> > for finding this subtle condition with syzbot, but this is quite
> > inaccurate. To be exposed to this issue, the user would need to
> > have the fou module loaded (it won't autoload), which is used quite
> > rarely, and, on top of that, have a UDP tunnel configured. It wouldn't
> > have been the kind of "evil packet crashes the internet" scenario you
> > were dreaming of ;)
> 
> Okay, I see. Full bug assessment is hard. I mess it both ways for
> different bugs.
> But I did not claim that it does not require some setup :)
> And maybe there is somebody important on the internet that uses such
> setup. Who knows.

Black hats, if no one else.  ;-)

							Thanx, Paul