On Sat, Apr 10, 2021 at 11:51 AM Phillip Potter <p...@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+2e406a9ac75bb71d4...@syzkaller.appspotmail.com > Signed-off-by: Phillip Potter <p...@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.
