From: John Fastabend <john.fastabend@gmail.com>
To: Yonghong Song <yhs@fb.com>,
ast@fb.com, daniel@iogearbox.net, netdev@vger.kernel.org
Cc: kernel-team@fb.com
Subject: Re: [PATCH bpf-next] bpf: fix sock hashmap kmalloc warning
Date: Wed, 16 May 2018 14:14:05 -0700 [thread overview]
Message-ID: <063ac13b-62d3-113a-1f93-a61235c7a078@gmail.com> (raw)
In-Reply-To: <20180516210626.776403-1-yhs@fb.com>
On 05/16/2018 02:06 PM, Yonghong Song wrote:
> syzbot reported a kernel warning below:
> WARNING: CPU: 0 PID: 4499 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70 mm/slab_common.c:996
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 0 PID: 4499 Comm: syz-executor050 Not tainted 4.17.0-rc3+ #9
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> panic+0x22f/0x4de kernel/panic.c:184
> __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
> report_bug+0x252/0x2d0 lib/bug.c:186
> fixup_bug arch/x86/kernel/traps.c:178 [inline]
> do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> RIP: 0010:kmalloc_slab+0x56/0x70 mm/slab_common.c:996
> RSP: 0018:ffff8801d907fc58 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff8801aeecb280 RCX: ffffffff8185ebd7
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000ffffffe1
> RBP: ffff8801d907fc58 R08: ffff8801adb5e1c0 R09: ffffed0035a84700
> R10: ffffed0035a84700 R11: ffff8801ad423803 R12: ffff8801aeecb280
> R13: 00000000fffffff4 R14: ffff8801ad891a00 R15: 00000000014200c0
> __do_kmalloc mm/slab.c:3713 [inline]
> __kmalloc+0x25/0x760 mm/slab.c:3727
> kmalloc include/linux/slab.h:517 [inline]
> map_get_next_key+0x24a/0x640 kernel/bpf/syscall.c:858
> __do_sys_bpf kernel/bpf/syscall.c:2131 [inline]
> __se_sys_bpf kernel/bpf/syscall.c:2096 [inline]
> __x64_sys_bpf+0x354/0x4f0 kernel/bpf/syscall.c:2096
> do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The test case is against sock hashmap with a key size 0xffffffe1.
> Such a large key size will cause the below code in function
> sock_hash_alloc() overflowing and produces a smaller elem_size,
> hence map creation will be successful.
> htab->elem_size = sizeof(struct htab_elem) +
> round_up(htab->map.key_size, 8);
>
> Later, when map_get_next_key is called and kernel tries
> to allocate the key unsuccessfully, it will issue
> the above warning.
>
> Similar to hashtab, ensure the key size is at most
> MAX_BPF_STACK for a successful map creation.
>
> Fixes: 81110384441a ("bpf: sockmap, add hash map support")
> Reported-by: syzbot+e4566d29080e7f3460ff@syzkaller.appspotmail.com
> Signed-off-by: Yonghong Song <yhs@fb.com>
> ---
> kernel/bpf/sockmap.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
> index 56879c9fd3a4..79f5e8988889 100644
> --- a/kernel/bpf/sockmap.c
> +++ b/kernel/bpf/sockmap.c
> @@ -1990,6 +1990,12 @@ static struct bpf_map *sock_hash_alloc(union bpf_attr *attr)
> attr->map_flags & ~SOCK_CREATE_FLAG_MASK)
> return ERR_PTR(-EINVAL);
>
> + if (attr->key_size > MAX_BPF_STACK)
> + /* eBPF programs initialize keys on stack, so they cannot be
> + * larger than max stack size
> + */
> + return ERR_PTR(-E2BIG);
> +
> err = bpf_tcp_ulp_register();
> if (err && err != -EEXIST)
> return ERR_PTR(err);
>
Thanks!
Acked-by: John Fastabend <john.fastabend@gmail.com>
next prev parent reply other threads:[~2018-05-16 21:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-16 21:06 [PATCH bpf-next] bpf: fix sock hashmap kmalloc warning Yonghong Song
2018-05-16 21:14 ` John Fastabend [this message]
2018-05-16 22:58 ` Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=063ac13b-62d3-113a-1f93-a61235c7a078@gmail.com \
--to=john.fastabend@gmail.com \
--cc=ast@fb.com \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).