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+e4566d29080e7f346...@syzkaller.appspotmail.com
> Signed-off-by: Yonghong Song <y...@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.fastab...@gmail.com>
