From: Phillip Potter <phil@philpotter.co.uk>
To: Eric Dumazet <edumazet@google.com>
Cc: David Miller <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Willem de Bruijn <willemb@google.com>,
linmiaohe <linmiaohe@huawei.com>,
Yunsheng Lin <linyunsheng@huawei.com>,
Alexander Lobakin <alobakin@pm.me>,
Marco Elver <elver@google.com>,
Guillaume Nault <gnault@redhat.com>,
Dongseok Yi <dseok.yi@samsung.com>,
Al Viro <viro@zeniv.linux.org.uk>,
vladimir.oltean@nxp.com, netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] net: core: sk_buff: zero-fill skb->data in __alloc_skb function
Date: Sun, 11 Apr 2021 00:33:55 +0100 [thread overview]
Message-ID: <YHI143tR7iSCpV6x@KernelVM> (raw)
In-Reply-To: <CANn89iK4HuKv4AgY5PPWGEEihNEFxGhhqpBp7zv-FfCcJyboDg@mail.gmail.com>
On Sat, Apr 10, 2021 at 01:00:34PM +0200, Eric Dumazet wrote:
> On Sat, Apr 10, 2021 at 12:12 PM Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Sat, Apr 10, 2021 at 11:51 AM Phillip Potter <phil@philpotter.co.uk> wrote:
> > >
> > > Zero-fill skb->data in __alloc_skb function of net/core/skbuff.c,
> > > up to start of struct skb_shared_info bytes. Fixes a KMSAN-found
> > > uninit-value bug reported by syzbot at:
> > > https://syzkaller.appspot.com/bug?id=abe95dc3e3e9667fc23b8d81f29ecad95c6f106f
> > >
> > > Reported-by: syzbot+2e406a9ac75bb71d4b7a@syzkaller.appspotmail.com
> > > Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
> > > ---
> > > net/core/skbuff.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > > index 785daff48030..9ac26cdb5417 100644
> > > --- a/net/core/skbuff.c
> > > +++ b/net/core/skbuff.c
> > > @@ -215,6 +215,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
> > > * to allow max possible filling before reallocation.
> > > */
> > > size = SKB_WITH_OVERHEAD(ksize(data));
> > > + memset(data, 0, size);
> > > prefetchw(data + size);
> >
> >
> > Certainly not.
> >
> > There is a difference between kmalloc() and kzalloc()
> >
> > Here you are basically silencing KMSAN and make it useless.
> >
> > Please fix the real issue, or stop using KMSAN if it bothers you.
>
> My understanding of the KMSAN bug (when I released it months ago) was
> that it was triggered by some invalid assumptions in geneve_xmit()
>
> The syzbot repro sends a packet with a very small size (Ethernet
> header only) and no IP/IPv6 header
>
> Fix for ipv4 part (sorry, not much time during week end to test all this)
>
> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> index e3b2375ac5eb55f544bbc1f309886cc9be189fd1..0a72779bc74bc50c20c34c05b2c525cca829f33c
> 100644
> --- a/drivers/net/geneve.c
> +++ b/drivers/net/geneve.c
> @@ -892,6 +892,9 @@ static int geneve_xmit_skb(struct sk_buff *skb,
> struct net_device *dev,
> __be16 sport;
> int err;
>
> + if (!pskb_network_may_pull(skb, sizeof(struct iphdr))
> + return -EINVAL;
> +
> sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
> rt = geneve_get_v4_rt(skb, dev, gs4, &fl4, info,
> geneve->cfg.info.key.tp_dst, sport);
Dear Eric,
Thank you for your help/feedback. I have crafted a patch using your code
above and the equivalent check for geneve6_xmit_skb, and this works for
me on my local KMSAN build. I am also running it through syzbot to check
there as well. I will send out with appropriate attribution assuming all
is OK on the testing front.
Regards,
Phil
prev parent reply other threads:[~2021-04-10 23:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-10 9:51 [PATCH] net: core: sk_buff: zero-fill skb->data in __alloc_skb function Phillip Potter
2021-04-10 10:12 ` Eric Dumazet
2021-04-10 11:00 ` Eric Dumazet
2021-04-10 23:33 ` Phillip Potter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YHI143tR7iSCpV6x@KernelVM \
--to=phil@philpotter.co.uk \
--cc=alobakin@pm.me \
--cc=davem@davemloft.net \
--cc=dseok.yi@samsung.com \
--cc=edumazet@google.com \
--cc=elver@google.com \
--cc=gnault@redhat.com \
--cc=kuba@kernel.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linyunsheng@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=vladimir.oltean@nxp.com \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.