netdev - Re: [PATCH] skbuff: Reallocate to ksize() in __build_skb

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:   Wed, 7 Dec 2022 10:19:04 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Kees Cook <keescook@...omium.org>,
        "David S. Miller" <davem@...emloft.net>
Cc:     syzbot+fda18eaa8c12534ccb3b@...kaller.appspotmail.com,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Pavel Begunkov <asml.silence@...il.com>,
        pepsipu <soopthegoop@...il.com>,
        kasan-dev <kasan-dev@...glegroups.com>,
        Andrii Nakryiko <andrii@...nel.org>, ast@...nel.org,
        bpf <bpf@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Hao Luo <haoluo@...gle.com>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        John Fastabend <john.fastabend@...il.com>, jolsa@...nel.org,
        KP Singh <kpsingh@...nel.org>, martin.lau@...ux.dev,
        Stanislav Fomichev <sdf@...gle.com>, song@...nel.org,
        Yonghong Song <yhs@...com>, netdev@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Menglong Dong <imagedong@...cent.com>,
        David Ahern <dsahern@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Luiz Augusto von Dentz <luiz.von.dentz@...el.com>,
        Richard Gobert <richardbgobert@...il.com>,
        Andrey Konovalov <andreyknvl@...il.com>,
        David Rientjes <rientjes@...gle.com>,
        linux-hardening@...r.kernel.org
Subject: Re: [PATCH] skbuff: Reallocate to ksize() in __build_skb_around()

On 12/7/22 00:17, Kees Cook wrote:
> When build_skb() is passed a frag_size of 0, it means the buffer came
> from kmalloc. In these cases, ksize() is used to find its actual size,
> but since the allocation may not have been made to that size, actually
> perform the krealloc() call so that all the associated buffer size
> checking will be correctly notified. For example, syzkaller reported:
> 
>   BUG: KASAN: slab-out-of-bounds in __build_skb_around+0x235/0x340 net/core/skbuff.c:294
>   Write of size 32 at addr ffff88802aa172c0 by task syz-executor413/5295
> 
> For bpf_prog_test_run_skb(), which uses a kmalloc()ed buffer passed to
> build_skb().

Weren't all such kmalloc() users converted to kmalloc_size_roundup() to
prevent this?

> Reported-by: syzbot+fda18eaa8c12534ccb3b@...kaller.appspotmail.com
> Link: https://groups.google.com/g/syzkaller-bugs/c/UnIKxTtU5-0/m/-wbXinkgAQAJ
> Fixes: 38931d8989b5 ("mm: Make ksize() a reporting-only function")
> Cc: "David S. Miller" <davem@...emloft.net>
> Cc: Eric Dumazet <edumazet@...gle.com>
> Cc: Jakub Kicinski <kuba@...nel.org>
> Cc: Paolo Abeni <pabeni@...hat.com>
> Cc: Pavel Begunkov <asml.silence@...il.com>
> Cc: pepsipu <soopthegoop@...il.com>
> Cc: syzbot+fda18eaa8c12534ccb3b@...kaller.appspotmail.com
> Cc: Vlastimil Babka <vbabka@...e.cz>
> Cc: kasan-dev <kasan-dev@...glegroups.com>
> Cc: Andrii Nakryiko <andrii@...nel.org>
> Cc: ast@...nel.org
> Cc: bpf <bpf@...r.kernel.org>
> Cc: Daniel Borkmann <daniel@...earbox.net>
> Cc: Hao Luo <haoluo@...gle.com>
> Cc: Jesper Dangaard Brouer <hawk@...nel.org>
> Cc: John Fastabend <john.fastabend@...il.com>
> Cc: jolsa@...nel.org
> Cc: KP Singh <kpsingh@...nel.org>
> Cc: martin.lau@...ux.dev
> Cc: Stanislav Fomichev <sdf@...gle.com>
> Cc: song@...nel.org
> Cc: Yonghong Song <yhs@...com>
> Cc: netdev@...r.kernel.org
> Cc: LKML <linux-kernel@...r.kernel.org>
> Signed-off-by: Kees Cook <keescook@...omium.org>
> ---
>  net/core/skbuff.c | 18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 1d9719e72f9d..b55d061ed8b4 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -274,7 +274,23 @@ static void __build_skb_around(struct sk_buff *skb, void *data,
>  			       unsigned int frag_size)
>  {
>  	struct skb_shared_info *shinfo;
> -	unsigned int size = frag_size ? : ksize(data);
> +	unsigned int size = frag_size;
> +
> +	/* When frag_size == 0, the buffer came from kmalloc, so we
> +	 * must find its true allocation size (and grow it to match).
> +	 */
> +	if (unlikely(size == 0)) {
> +		void *resized;
> +
> +		size = ksize(data);
> +		/* krealloc() will immediate return "data" when
> +		 * "ksize(data)" is requested: it is the existing upper
> +		 * bounds. As a result, GFP_ATOMIC will be ignored.
> +		 */
> +		resized = krealloc(data, size, GFP_ATOMIC);
> +		if (WARN_ON(resized != data))

WARN_ON_ONCE() could be sufficient as either this is impossible to hit by
definition, or something went very wrong (a patch screwed ksize/krealloc?)
and it can be hit many times?

> +			data = resized;

In that "impossible" case, this could also end up as NULL due to GFP_ATOMIC
allocation failure, but maybe it's really impractical to do anything about it...

> +	}
>  
>  	size -= SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>