netdev - Re: [PATCH bpf-next] bpf: reject too big ctx_size_in for raw

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]

Message-ID: <b8b16115-4fba-265f-b0a5-33af02a75bbb@fb.com>
Date:   Tue, 12 Jan 2021 21:17:41 -0800
From:   Yonghong Song <yhs@...com>
To:     Song Liu <songliubraving@...com>, <bpf@...r.kernel.org>,
        <netdev@...r.kernel.org>
CC:     <ast@...nel.org>, <daniel@...earbox.net>, <andrii@...nel.org>,
        <john.fastabend@...il.com>, <kpsingh@...omium.org>,
        <kernel-team@...com>,
        <syzbot+4f98876664c7337a4ae6@...kaller.appspotmail.com>,
        <stable@...r.kernel.org>
Subject: Re: [PATCH bpf-next] bpf: reject too big ctx_size_in for raw_tp test
 run



On 1/12/21 3:42 PM, Song Liu wrote:
> syzbot reported a WARNING for allocating too big memory:
> 
> WARNING: CPU: 1 PID: 8484 at mm/page_alloc.c:4976 __alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:5011
> Modules linked in:
> CPU: 1 PID: 8484 Comm: syz-executor862 Not tainted 5.11.0-rc2-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> RIP: 0010:__alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:4976
> Code: 00 00 0c 00 0f 85 a7 00 00 00 8b 3c 24 4c 89 f2 44 89 e6 c6 44 24 70 00 48 89 6c 24 58 e8 d0 d7 ff ff 49 89 c5 e9 ea fc ff ff <0f> 0b e9 b5 fd ff ff 89 74 24 14 4c 89 4c 24 08 4c 89 74 24 18 e8
> RSP: 0018:ffffc900012efb10 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: 1ffff9200025df66 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000140dc0
> RBP: 0000000000140dc0 R08: 0000000000000000 R09: 0000000000000000
> R10: ffffffff81b1f7e1 R11: 0000000000000000 R12: 0000000000000014
> R13: 0000000000000014 R14: 0000000000000000 R15: 0000000000000000
> FS:  000000000190c880(0000) GS:ffff8880b9e00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f08b7f316c0 CR3: 0000000012073000 CR4: 00000000001506f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> alloc_pages_current+0x18c/0x2a0 mm/mempolicy.c:2267
> alloc_pages include/linux/gfp.h:547 [inline]
> kmalloc_order+0x2e/0xb0 mm/slab_common.c:837
> kmalloc_order_trace+0x14/0x120 mm/slab_common.c:853
> kmalloc include/linux/slab.h:557 [inline]
> kzalloc include/linux/slab.h:682 [inline]
> bpf_prog_test_run_raw_tp+0x4b5/0x670 net/bpf/test_run.c:282
> bpf_prog_test_run kernel/bpf/syscall.c:3120 [inline]
> __do_sys_bpf+0x1ea9/0x4f10 kernel/bpf/syscall.c:4398
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x440499
> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007ffe1f3bfb18 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440499
> RDX: 0000000000000048 RSI: 0000000020000600 RDI: 000000000000000a
> RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401ca0
> R13: 0000000000401d30 R14: 0000000000000000 R15: 0000000000000000
> 
> This is because we didn't filter out too big ctx_size_in. Fix it by
> rejecting ctx_size_in that are bigger than MAX_BPF_FUNC_ARGS (12) u64
> numbers.
> 
> Reported-by: syzbot+4f98876664c7337a4ae6@...kaller.appspotmail.com
> Fixes: 1b4d60ec162f ("bpf: Enable BPF_PROG_TEST_RUN for raw_tracepoint")
> Cc: stable@...r.kernel.org # v5.10+
> Signed-off-by: Song Liu <songliubraving@...com>

Maybe this should target to bpf tree?

Acked-by: Yonghong Song <yhs@...com>