Re: [PATCH] skbuff: Reallocate to ksize() in __build_skb_around()
From: Vlastimil Babka
Date: Wed Dec 07 2022 - 04:19:25 EST
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@xxxxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxx>
> Cc: Eric Dumazet <edumazet@xxxxxxxxxx>
> Cc: Jakub Kicinski <kuba@xxxxxxxxxx>
> Cc: Paolo Abeni <pabeni@xxxxxxxxxx>
> Cc: Pavel Begunkov <asml.silence@xxxxxxxxx>
> Cc: pepsipu <soopthegoop@xxxxxxxxx>
> Cc: syzbot+fda18eaa8c12534ccb3b@xxxxxxxxxxxxxxxxxxxxxxxxx
> Cc: Vlastimil Babka <vbabka@xxxxxxx>
> Cc: kasan-dev <kasan-dev@xxxxxxxxxxxxxxxx>
> Cc: Andrii Nakryiko <andrii@xxxxxxxxxx>
> Cc: ast@xxxxxxxxxx
> Cc: bpf <bpf@xxxxxxxxxxxxxxx>
> Cc: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
> Cc: Hao Luo <haoluo@xxxxxxxxxx>
> Cc: Jesper Dangaard Brouer <hawk@xxxxxxxxxx>
> Cc: John Fastabend <john.fastabend@xxxxxxxxx>
> Cc: jolsa@xxxxxxxxxx
> Cc: KP Singh <kpsingh@xxxxxxxxxx>
> Cc: martin.lau@xxxxxxxxx
> Cc: Stanislav Fomichev <sdf@xxxxxxxxxx>
> Cc: song@xxxxxxxxxx
> Cc: Yonghong Song <yhs@xxxxxx>
> Cc: netdev@xxxxxxxxxxxxxxx
> Cc: LKML <linux-kernel@xxxxxxxxxxxxxxx>
> Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx>
> ---
> 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));
>