From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Borkmann <daniel@iogearbox.net>
Subject: Re: [PATCH bpf-next] bpf: fix sock hashmap kmalloc warning
Date: Thu, 17 May 2018 00:58:28 +0200
Message-ID: <46819ed0-8cf4-4e53-1f80-a02c2f8ac287@iogearbox.net>
References: <20180516210626.776403-1-yhs@fb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: kernel-team@fb.com
To: Yonghong Song <yhs@fb.com>, ast@fb.com, netdev@vger.kernel.org
Return-path: <netdev-owner@vger.kernel.org>
Received: from www62.your-server.de ([213.133.104.62]:48204 "EHLO
        www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751395AbeEPW6a (ORCPT
        <rfc822;netdev@vger.kernel.org>); Wed, 16 May 2018 18:58:30 -0400
In-Reply-To: <20180516210626.776403-1-yhs@fb.com>
Content-Language: en-US
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On 05/16/2018 11: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>

Applied to bpf-next, thanks Yonghong!