> On Jan 12, 2021, at 9:17 PM, Yonghong Song <yhs@xxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxx
>> Fixes: 1b4d60ec162f ("bpf: Enable BPF_PROG_TEST_RUN for raw_tracepoint")
>> Cc: stable@xxxxxxxxxxxxxxx # v5.10+
>> Signed-off-by: Song Liu <songliubraving@xxxxxx>
>
> 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?
>
> Acked-by: Yonghong Song <yhs@xxxxxx>
Thanks!
