Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <000000000000a96c0b05e97f0444@google.com> <CAM0EoMnJ=STtk5BnZ9oJtnkXY2Q+Px2cKa4gowFRGpp40UNKww@mail.gmail.com>
 <CAM0EoMm9uBQQepMb5bda1vR-Okw-tPp2nnf6TvfA0FzPu_D_2A@mail.gmail.com>
 <CANn89i+4pgJe8M1cjLF6SkqG1Yp6e+5J2xEkMdSChiVYKMC09g@mail.gmail.com> <CAM0EoMkLdOUQ3yrBuYsLdZvqniZ_r0VoACzOzKCo1VVzYeyPbw@mail.gmail.com>
In-Reply-To: <CAM0EoMkLdOUQ3yrBuYsLdZvqniZ_r0VoACzOzKCo1VVzYeyPbw@mail.gmail.com>
From:   Jamal Hadi Salim <jhs@mojatatu.com>
Date:   Sun, 25 Sep 2022 13:13:20 -0400
Message-ID: <CAM0EoMmr8trH0EOtOfvTpYiTq1tt7RUamf1u_R0+USOU_gYUVg@mail.gmail.com>
Subject: Re: [syzbot] WARNING in u32_change
To:     Eric Dumazet <edumazet@google.com>
Cc:     syzbot <syzbot+a2c4601efc75848ba321@syzkaller.appspotmail.com>,
        David Miller <davem@davemloft.net>,
        Jiri Pirko <jiri@resnulli.us>,
        Jakub Kicinski <kuba@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        netdev <netdev@vger.kernel.org>, Paolo Abeni <pabeni@redhat.com>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
        Cong Wang <xiyou.wangcong@gmail.com>,
        Kees Cook <keescook@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

To be clear, that splat didnt happen for me.
Is there something else syzbot does to activate it?

cheers,
jamal

On Sun, Sep 25, 2022 at 1:08 PM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>
> Yes, after testing i realize there is nothing wrong here.
> What warning was i supposed to see from running the reproducer?
>
> We will still add the test will multiple keys later
>
> cheers,
> jamal
>
> On Sun, Sep 25, 2022 at 12:29 PM Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Sun, Sep 25, 2022 at 9:14 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> > >
> > > On Sun, Sep 25, 2022 at 11:38 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> > > >
> > > > Is there a way to tell the boat "looking into it?"
> > >
> > >
> > > I guess I have to swim across to it to get the message;->
> > >
> > > I couldnt see the warning message  but it is obvious by inspection that
> > > the memcpy is broken. We should add more test coverage.
> > > This should fix it. Will send a formal patch later:
> > >
> > > diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
> > > index 4d27300c2..591cbbf27 100644
> > > --- a/net/sched/cls_u32.c
> > > +++ b/net/sched/cls_u32.c
> > > @@ -1019,7 +1019,7 @@ static int u32_change(struct net *net, struct
> > > sk_buff *in_skb,
> > >         }
> > >
> > >         s = nla_data(tb[TCA_U32_SEL]);
> > > -       sel_size = struct_size(s, keys, s->nkeys);
> > > +       sel_size = struct_size(s, keys, s->nkeys) + sizeof(n->sel);
> > >         if (nla_len(tb[TCA_U32_SEL]) < sel_size) {
> > >                 err = -EINVAL;
> > >                 goto erridr;
> >
> > This patch is not needed, please look at struct_size() definition.
> >
> > Here, we might switch to unsafe_memcpy() instead of memcpy()