Re: [PATCH bpf-next] bpf: reject too big ctx_size_in for raw_tp test run

[Yonghong Song <yhs@fb.com>]

On 1/13/21 1:48 PM, Song Liu wrote:
> 
> 
>> On Jan 12, 2021, at 9:17 PM, Yonghong Song <yhs@fb.com> wrote:
>>
>>
>>
>> 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@syzkaller.appspotmail.com
>>> Fixes: 1b4d60ec162f ("bpf: Enable BPF_PROG_TEST_RUN for raw_tracepoint")
>>> Cc: stable@vger.kernel.org # v5.10+
>>> Signed-off-by: Song Liu <songliubraving@fb.com>
>>
>> Maybe this should target to bpf tree?
> 
> IIRC, we direct fixes to current release under rc (5.11) to bpf tree. This
> one is for 5.10 and 5.11, so should go bpf-next, no?

I don't know where it should go first. Maintainers know better. But it 
should go to 5.10, 5.11 (currently rc4) and bpf-next.

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