Netdev Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH bpf-next] bpf: reject too big ctx_size_in for raw_tp test run
@ 2021-01-12 23:42 Song Liu
  2021-01-13  5:17 ` Yonghong Song
  0 siblings, 1 reply; 5+ messages in thread
From: Song Liu @ 2021-01-12 23:42 UTC (permalink / raw)
  To: bpf, netdev
  Cc: ast, daniel, andrii, john.fastabend, kpsingh, kernel-team,
	Song Liu, syzbot+4f98876664c7337a4ae6, stable

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>
---
 net/bpf/test_run.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
index 23dfb2010ba69..58bcb8c849d54 100644
--- a/net/bpf/test_run.c
+++ b/net/bpf/test_run.c
@@ -272,7 +272,8 @@ int bpf_prog_test_run_raw_tp(struct bpf_prog *prog,
 	    kattr->test.repeat)
 		return -EINVAL;
 
-	if (ctx_size_in < prog->aux->max_ctx_offset)
+	if (ctx_size_in < prog->aux->max_ctx_offset ||
+	    ctx_size_in > MAX_BPF_FUNC_ARGS * sizeof(u64))
 		return -EINVAL;
 
 	if ((kattr->test.flags & BPF_F_TEST_RUN_ON_CPU) == 0 && cpu != 0)
-- 
2.24.1


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH bpf-next] bpf: reject too big ctx_size_in for raw_tp test run
  2021-01-12 23:42 [PATCH bpf-next] bpf: reject too big ctx_size_in for raw_tp test run Song Liu
@ 2021-01-13  5:17 ` Yonghong Song
  2021-01-13 21:48   ` Song Liu
  0 siblings, 1 reply; 5+ messages in thread
From: Yonghong Song @ 2021-01-13  5:17 UTC (permalink / raw)
  To: Song Liu, bpf, netdev
  Cc: ast, daniel, andrii, john.fastabend, kpsingh, kernel-team,
	syzbot+4f98876664c7337a4ae6, stable



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?

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH bpf-next] bpf: reject too big ctx_size_in for raw_tp test run
  2021-01-13  5:17 ` Yonghong Song
@ 2021-01-13 21:48   ` Song Liu
  2021-01-13 23:28     ` Yonghong Song
  0 siblings, 1 reply; 5+ messages in thread
From: Song Liu @ 2021-01-13 21:48 UTC (permalink / raw)
  To: Yonghong Song
  Cc: bpf, Networking, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, John Fastabend, KP Singh, Kernel Team,
	syzbot+4f98876664c7337a4ae6, stable



> 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?

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

Thanks!


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH bpf-next] bpf: reject too big ctx_size_in for raw_tp test run
  2021-01-13 21:48   ` Song Liu
@ 2021-01-13 23:28     ` Yonghong Song
  2021-01-14  3:41       ` Alexei Starovoitov
  0 siblings, 1 reply; 5+ messages in thread
From: Yonghong Song @ 2021-01-13 23:28 UTC (permalink / raw)
  To: Song Liu
  Cc: bpf, Networking, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, John Fastabend, KP Singh, Kernel Team,
	syzbot+4f98876664c7337a4ae6, stable



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!
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH bpf-next] bpf: reject too big ctx_size_in for raw_tp test run
  2021-01-13 23:28     ` Yonghong Song
@ 2021-01-14  3:41       ` Alexei Starovoitov
  0 siblings, 0 replies; 5+ messages in thread
From: Alexei Starovoitov @ 2021-01-14  3:41 UTC (permalink / raw)
  To: Yonghong Song
  Cc: Song Liu, bpf, Networking, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, John Fastabend, KP Singh, Kernel Team,
	syzbot+4f98876664c7337a4ae6, stable

On Wed, Jan 13, 2021 at 3:28 PM Yonghong Song <yhs@fb.com> wrote:
>
>
>
> 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.

Not sure what is the disagreement here.
It's clearly a fix. Hence it was applied to bpf tree.
Song, please mark subj as [PATCH bpf] not to confuse CI,
since it's using this tag to test patches against appropriate tree.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-12 23:42 [PATCH bpf-next] bpf: reject too big ctx_size_in for raw_tp test run Song Liu
2021-01-13  5:17 ` Yonghong Song
2021-01-13 21:48   ` Song Liu
2021-01-13 23:28     ` Yonghong Song
2021-01-14  3:41       ` Alexei Starovoitov

Netdev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/netdev/0 netdev/git/0.git
	git clone --mirror https://lore.kernel.org/netdev/1 netdev/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 netdev netdev/ https://lore.kernel.org/netdev \
		netdev@vger.kernel.org
	public-inbox-index netdev

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.netdev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git