netdev - Re: [PATCH bpf-next] bpf: fix sock hashmap kmalloc warning

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, 16 May 2018 14:14:05 -0700
From:   John Fastabend <john.fastabend@...il.com>
To:     Yonghong Song <yhs@...com>, ast@...com, daniel@...earbox.net,
        netdev@...r.kernel.org
Cc:     kernel-team@...com
Subject: Re: [PATCH bpf-next] bpf: fix sock hashmap kmalloc warning

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@...kaller.appspotmail.com
> Signed-off-by: Yonghong Song <yhs@...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@...il.com>