netdev - Re: [PATCH] net: core: sk_buff: zero-fill skb->data in __alloc

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]

Date:   Sat, 10 Apr 2021 12:12:38 +0200
From:   Eric Dumazet <edumazet@...gle.com>
To:     Phillip Potter <phil@...lpotter.co.uk>
Cc:     davem@...emloft.net, kuba@...nel.org, willemb@...gle.com,
        linmiaohe@...wei.com, linyunsheng@...wei.com, alobakin@...me,
        elver@...gle.com, gnault@...hat.com, dseok.yi@...sung.com,
        viro@...iv.linux.org.uk, vladimir.oltean@....com,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: core: sk_buff: zero-fill skb->data in __alloc_skb function

On Sat, Apr 10, 2021 at 11:51 AM Phillip Potter <phil@...lpotter.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@...kaller.appspotmail.com
> Signed-off-by: Phillip Potter <phil@...lpotter.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.