| 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
| ||
|
Message-ID: <202408281719.8BBA257@keescook>
Date: Wed, 28 Aug 2024 17:38:36 -0700
From: Kees Cook <kees@...nel.org>
To: Juefei Pu <juefei.pu@...il.ucr.edu>
Cc: luto@...capital.net, wad@...omium.org, linux-kernel@...r.kernel.org,
linux-hardening@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: BUG: null pointer dereference in seccomp
On Tue, Aug 27, 2024 at 09:09:49PM -0700, Juefei Pu wrote:
> Hello,
> We found the following null-pointer-dereference issue using syzkaller
> on Linux v6.10.
In seccomp! Yikes.
> Unfortunately, the syzkaller failed to generate a reproducer.
That's a bummer.
> But at least we have the report:
>
> Oops: general protection fault, probably for non-canonical address
> 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI
> KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
> CPU: 0 PID: 4493 Comm: systemd-journal Not tainted 6.10.0 #13
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> RIP: 0010:__bpf_prog_run include/linux/filter.h:691 [inline]
This doesn't look like a NULL deref, this looks like a corrupted
pointer: 0xdffffc0000000006. Is prog bad or dfunc bad? I assume the
former, as dfunc is hard-coded below...
ret = dfunc(ctx, prog->insnsi, prog->bpf_func);
> RIP: 0010:bpf_prog_run include/linux/filter.h:698 [inline]
return __bpf_prog_run(prog, ctx, bpf_dispatcher_nop_func);
> RIP: 0010:bpf_prog_run_pin_on_cpu include/linux/filter.h:715 [inline]
ret = bpf_prog_run(prog, ctx);
> RIP: 0010:seccomp_run_filters+0x17a/0x3f0 kernel/seccomp.c:426
u32 cur_ret = bpf_prog_run_pin_on_cpu(f->prog, sd);
> Code: 00 00 e8 99 36 d2 ff 0f 1f 44 00 00 e8 cf 58 ff ff 48 8d 5d 48
> 48 83 c5 30 48 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c
> 08 00 74 08 48 89 ef e8 c8 63 62 00 4c 8b 5d 00 48 8b 3c 24
> RSP: 0018:ffffc90002cb7be0 EFLAGS: 00010206
> RAX: 0000000000000006 RBX: 0000000000000048 RCX: dffffc0000000000
> RDX: 0000000000000000 RSI: 00000000000002a4 RDI: ffffffff8b517360
> RBP: 0000000000000030 R08: ffffffff8191f8eb R09: 1ffff11004039e86
> R10: dffffc0000000000 R11: ffffffffa00016d0 R12: 000000007fff0000
> R13: ffff88801f84a800 R14: ffffc90002cb7df0 R15: 000000007fff0000
> FS: 00007f897e849900(0000) GS:ffff888063a00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f897d771b08 CR3: 00000000195fe000 CR4: 0000000000350ef0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> <TASK>
> __seccomp_filter+0x46f/0x1c70 kernel/seccomp.c:1222
> syscall_trace_enter+0xa4/0x140 kernel/entry/common.c:52
> syscall_enter_from_user_mode_work include/linux/entry-common.h:168 [inline]
> syscall_enter_from_user_mode include/linux/entry-common.h:198 [inline]
> do_syscall_64+0x5d/0x150 arch/x86/entry/common.c:79
> entry_SYSCALL_64_after_hwframe+0x67/0x6f
Has anything changed in BPF in this area lately?
> RIP: 0033:0x7f897ed171e4
> Code: 84 00 00 00 00 00 44 89 54 24 0c e8 36 58 f9 ff 44 8b 54 24 0c
> 44 89 e2 48 89 ee 41 89 c0 bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d
> 00 f0 ff ff 77 34 44 89 c7 89 44 24 0c e8 68 58 f9 ff 8b 44
> RSP: 002b:00007ffd4ae74a60 EFLAGS: 00000293 ORIG_RAX: 0000000000000101
> RAX: ffffffffffffffda RBX: 00005627cd785ed0 RCX: 00007f897ed171e4
> RDX: 0000000000290000 RSI: 00007f897f010d0a RDI: 00000000ffffff9c
> RBP: 00007f897f010d0a R08: 0000000000000000 R09: 0034353132303865
> R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000290000
> R13: 00007ffd4ae74d20 R14: 0000000000000000 R15: 00007ffd4ae74e28
> </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:__bpf_prog_run include/linux/filter.h:691 [inline]
> RIP: 0010:bpf_prog_run include/linux/filter.h:698 [inline]
> RIP: 0010:bpf_prog_run_pin_on_cpu include/linux/filter.h:715 [inline]
> RIP: 0010:seccomp_run_filters+0x17a/0x3f0 kernel/seccomp.c:426
> Code: 00 00 e8 99 36 d2 ff 0f 1f 44 00 00 e8 cf 58 ff ff 48 8d 5d 48
> 48 83 c5 30 48 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c
> 08 00 74 08 48 89 ef e8 c8 63 62 00 4c 8b 5d 00 48 8b 3c 24
> RSP: 0018:ffffc90002cb7be0 EFLAGS: 00010206
> RAX: 0000000000000006 RBX: 0000000000000048 RCX: dffffc0000000000
> RDX: 0000000000000000 RSI: 00000000000002a4 RDI: ffffffff8b517360
> RBP: 0000000000000030 R08: ffffffff8191f8eb R09: 1ffff11004039e86
> R10: dffffc0000000000 R11: ffffffffa00016d0 R12: 000000007fff0000
> R13: ffff88801f84a800 R14: ffffc90002cb7df0 R15: 000000007fff0000
> FS: 00007f897e849900(0000) GS:ffff888063a00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f521f8ca000 CR3: 00000000195fe000 CR4: 0000000000350ef0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> ----------------
> Code disassembly (best guess):
> 0: 00 00 add %al,(%rax)
> 2: e8 99 36 d2 ff call 0xffd236a0
> 7: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> c: e8 cf 58 ff ff call 0xffff58e0
> 11: 48 8d 5d 48 lea 0x48(%rbp),%rbx
> 15: 48 83 c5 30 add $0x30,%rbp
> 19: 48 89 e8 mov %rbp,%rax
> 1c: 48 c1 e8 03 shr $0x3,%rax
> 20: 48 b9 00 00 00 00 00 movabs $0xdffffc0000000000,%rcx
> 27: fc ff df
> * 2a: 80 3c 08 00 cmpb $0x0,(%rax,%rcx,1) <-- trapping instruction
> 2e: 74 08 je 0x38
> 30: 48 89 ef mov %rbp,%rdi
> 33: e8 c8 63 62 00 call 0x626400
> 38: 4c 8b 5d 00 mov 0x0(%rbp),%r11
> 3c: 48 8b 3c 24 mov (%rsp),%rdi
What's the movabs? I don't have anything like that in my vmlinux binary
output. Is this KASAN perhaps?
Regardless, I don't see how prog could be NULL. :( It shouldn't be
possible without some kind of major refcounting bug.
-Kees
--
Kees Cook
Powered by blists - more mailing lists