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)); >
