On Tue, Dec 19, 2017 at 10:59 PM, Eric Biggers <ebiggers3@xxxxxxxxx> wrote: > On Tue, Dec 19, 2017 at 12:41:01AM -0800, syzbot wrote: >> Hello, >> >> syzkaller hit the following crash on >> 6084b576dca2e898f5c101baef151f7bfdbb606d >> 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. >> >> Unfortunately, I don't have any reproducer for this bug yet. >> >> >> sctp: [Deprecated]: syz-executor6 (pid 4202) Use of int in max_burst >> socket option. >> Use struct sctp_assoc_value instead >> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 >> sctp: [Deprecated]: syz-executor4 (pid 4240) Use of int in max_burst >> socket option. >> Use struct sctp_assoc_value instead >> sctp: [Deprecated]: syz-executor4 (pid 4240) Use of int in max_burst >> socket option. >> Use struct sctp_assoc_value instead >> IP: __rb_insert lib/rbtree.c:126 [inline] >> IP: rb_insert_color+0x17/0x190 lib/rbtree.c:452 >> PGD 0 P4D 0 >> Oops: 0000 [#1] SMP >> Dumping ftrace buffer: >> (ftrace buffer empty) >> Modules linked in: >> CPU: 0 PID: 4244 Comm: modprobe Not tainted 4.15.0-rc3-next-20171214+ #67 >> Hardware name: Google Google Compute Engine/Google Compute Engine, >> BIOS Google 01/01/2011 >> RIP: 0010:__rb_insert lib/rbtree.c:126 [inline] >> RIP: 0010:rb_insert_color+0x17/0x190 lib/rbtree.c:452 >> RSP: 0018:ffffc900010a7c08 EFLAGS: 00010246 >> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff814ddcb9 >> RDX: ffff8801ebedf988 RSI: ffff8801ebfd6400 RDI: ffff88021413a408 >> RBP: ffffc900010a7c08 R08: 000000000002bcf8 R09: ffff88021413a400 >> R10: 0000000000000000 R11: 0000000000000000 R12: ffff88021413a400 >> R13: ffff8801ebedf990 R14: 00000000a34fc52a R15: ffff8801ebedf988 >> FS: 00007f85a5155700(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> CR2: 0000000000000008 CR3: 00000001eaccd006 CR4: 00000000001606f0 >> DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000 >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600 >> Call Trace: >> ext4_htree_store_dirent+0x122/0x160 fs/ext4/dir.c:488 >> htree_dirblock_to_tree+0x112/0x300 fs/ext4/namei.c:1019 >> ext4_htree_fill_tree+0xdf/0x410 fs/ext4/namei.c:1096 >> ext4_dx_readdir fs/ext4/dir.c:575 [inline] >> ext4_readdir+0x8cf/0xd70 fs/ext4/dir.c:122 >> iterate_dir+0xb8/0x200 fs/readdir.c:51 >> SYSC_getdents fs/readdir.c:231 [inline] >> SyS_getdents+0xcc/0x1b0 fs/readdir.c:212 >> entry_SYSCALL_64_fastpath+0x1f/0x96 >> RIP: 0033:0x7f85a4a45575 >> RSP: 002b:00007ffc9b5be120 EFLAGS: 00000246 ORIG_RAX: 000000000000004e >> RAX: ffffffffffffffda RBX: 00007f85a4d23e98 RCX: 00007f85a4a45575 >> RDX: 0000000000008000 RSI: 00005633094701e0 RDI: 0000000000000000 >> RBP: 00007f85a4d23e40 R08: 00005633094701e0 R09: 00007f85a4d23e90 >> R10: 0000000000000000 R11: 0000000000000246 R12: 00005633094701b0 >> R13: 0000000000018e21 R14: 0000000000000000 R15: 0000000000000004 >> Code: 48 85 d2 75 eb 5d c3 31 c0 5d c3 66 0f 1f 84 00 00 00 00 00 55 >> 48 8b 17 48 89 e5 48 85 d2 0f 84 4c 01 00 00 48 8b 02 a8 01 75 5e >> <48> 8b 48 08 49 89 c0 48 39 d1 74 54 48 85 c9 74 09 f6 01 01 0f >> RIP: __rb_insert lib/rbtree.c:126 [inline] RSP: ffffc900010a7c08 >> RIP: rb_insert_color+0x17/0x190 lib/rbtree.c:452 RSP: ffffc900010a7c08 >> CR2: 0000000000000008 >> BUG: unable to handle kernel paging request at 0000000100000001 >> ---[ end trace c403bd3ebad2ccb0 ]--- > > The line number in lib/rbtree.c seems to be slightly off. Looking at the > disassembly: > > ffffffff825b5ea0 <rb_insert_color>: > ffffffff825b5ea0: 55 push %rbp > ffffffff825b5ea1: 48 8b 17 mov (%rdi),%rdx > ffffffff825b5ea4: 48 89 e5 mov %rsp,%rbp > ffffffff825b5ea7: 48 85 d2 test %rdx,%rdx > ffffffff825b5eaa: 0f 84 4c 01 00 00 je ffffffff825b5ffc <rb_insert_color+0x15c> > ffffffff825b5eb0: 48 8b 02 mov (%rdx),%rax > ffffffff825b5eb3: a8 01 test $0x1,%al > ffffffff825b5eb5: 75 5e jne ffffffff825b5f15 <rb_insert_color+0x75> > ffffffff825b5eb7: 48 8b 48 08 mov 0x8(%rax),%rcx > > It crashed on 'mov 0x8(%rax),%rcx' which corresponds to > 'tmp = gparent->rb_right;' at lib/rbtree.c:131. So 'parent' was the root node, > but its color was red, while it is supposed to be black. > > No idea how that happened, but it's almost certainly not an ext4 bug. In fact > there is another report of this same crash that has a different call trace: > > Call Trace: > key_alloc_serial security/keys/key.c:170 [inline] > key_alloc+0x54c/0x5b0 security/keys/key.c:319 > keyring_alloc+0x4d/0xb0 security/keys/keyring.c:503 > install_process_keyring_to_cred.part.3+0x38/0x80 security/keys/process_keys.c:192 > install_process_keyring_to_cred security/keys/process_keys.c:634 [inline] > install_process_keyring security/keys/process_keys.c:217 [inline] > lookup_user_key+0x4ed/0x7c0 security/keys/process_keys.c:574 > SYSC_add_key security/keys/keyctl.c:114 [inline] > SyS_add_key+0xec/0x260 security/keys/keyctl.c:62 > entry_SYSCALL_64_fastpath+0x1f/0x96 My first hypothesis for an non-explainable, non-reproducible corruption would be a data race. Is there all locking in place?
