On Tue, Jan 02, 2018 at 08:58:01PM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 0e08c463db387a2adcb0243b15ab868a73f87807
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6d362cadd45dc0a12...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> audit: type=1400 audit(1514685224.971:7): avc: denied { map } for
> pid=3144 comm="syzkaller663366" path="/root/syzkaller663366580" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> WARNING: CPU: 1 PID: 3144 at kernel/bpf/verifier.c:2359
> adjust_ptr_min_max_vals+0x977/0x20a0 kernel/bpf/verifier.c:2359
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 3144 Comm: syzkaller663366 Not tainted 4.15.0-rc4-next-20171221+
> #78
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> panic+0x1e4/0x41c kernel/panic.c:183
> __warn+0x1dc/0x200 kernel/panic.c:547
> report_bug+0x211/0x2d0 lib/bug.c:184
> fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:177
> fixup_bug arch/x86/kernel/traps.c:246 [inline]
> do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:295
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314
> invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079
> RIP: 0010:adjust_ptr_min_max_vals+0x977/0x20a0 kernel/bpf/verifier.c:2359
> RSP: 0018:ffff8801c97ef198 EFLAGS: 00010293
> RAX: ffff8801c94e8240 RBX: ffff8801c8ee4b00 RCX: ffffffff817eebb7
> RDX: 0000000000000000 RSI: ffffc90000002048 RDI: ffffc90000002049
> RBP: ffff8801c97ef228 R08: 0000000000000000 R09: ffffffff858fa920
> R10: 0000000000000071 R11: ffffffff858f9d00 R12: 0000000000000000
> R13: 0000000000000001 R14: ffffc90000002048 R15: ffff8801c8e02040
> adjust_reg_min_max_vals kernel/bpf/verifier.c:2799 [inline]
> check_alu_op kernel/bpf/verifier.c:2997 [inline]
> do_check+0x67e0/0xae20 kernel/bpf/verifier.c:4448
> bpf_check+0x2b1b/0x49f0 kernel/bpf/verifier.c:5374
> bpf_prog_load+0xa2a/0x1b00 kernel/bpf/syscall.c:1192
> SYSC_bpf kernel/bpf/syscall.c:1724 [inline]
> SyS_bpf+0x1044/0x4420 kernel/bpf/syscall.c:1686
> entry_SYSCALL_64_fastpath+0x1f/0x96
that's an interesting bug.
If I decipher fuzzed bpf insns correctly the sequence:
r0 = 0x0
if r0 s<= 0x0 goto pc+0
r0 -= r1
causes:
if (WARN_ON_ONCE(known && (smin_val != smax_val))) {
and smin_val=1 smax_val=0
since the verifier did:
case BPF_JSLE:
false_reg->smin_value = max_t(s64, false_reg->smin_value, val +
1);
Not sure what the best fix yet.
