[syzbot] BUG: unable to handle kernel NULL pointer dereference in __lookup_slow (2)
Hello, syzbot found the following issue on: HEAD commit:d93a0d43 Merge tag 'block-5.12-2021-04-02' of git://git.ke.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16519431d0 kernel config: https://syzkaller.appspot.com/x/.config?x=71a75beb62b62a34 dashboard link: https://syzkaller.appspot.com/bug?extid=11c49ce9d4e7896f3406 compiler: Debian clang version 11.0.1-2 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+11c49ce9d4e7896f3...@syzkaller.appspotmail.com REISERFS (device loop4): Using r5 hash to sort names BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 6bb82067 P4D 6bb82067 PUD 6bb81067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 11072 Comm: syz-executor.4 Not tainted 5.12.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c90008f8fa20 EFLAGS: 00010246 RAX: 113872e8 RBX: dc00 RCX: 0004 RDX: RSI: 88802e9d9490 RDI: 88807f140190 RBP: 89c39740 R08: 81c9d4de R09: fbfff200a946 R10: fbfff200a946 R11: R12: R13: 88807f140190 R14: 111005d3b292 R15: 88802e9d9490 FS: 7f894af88700() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 6bb83000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __lookup_slow+0x240/0x370 fs/namei.c:1626 lookup_one_len+0x10e/0x200 fs/namei.c:2649 reiserfs_lookup_privroot+0x85/0x1e0 fs/reiserfs/xattr.c:980 reiserfs_fill_super+0x2a69/0x3160 fs/reiserfs/super.c:2176 mount_bdev+0x26c/0x3a0 fs/super.c:1367 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1497 do_new_mount fs/namespace.c:2903 [inline] path_mount+0x188a/0x29a0 fs/namespace.c:3233 do_mount fs/namespace.c:3246 [inline] __do_sys_mount fs/namespace.c:3454 [inline] __se_sys_mount+0x28c/0x320 fs/namespace.c:3431 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x46797a Code: 48 c7 c2 bc ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 b8 04 00 00 0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:7f894af87fa8 EFLAGS: 0206 ORIG_RAX: 00a5 RAX: ffda RBX: 2200 RCX: 0046797a RDX: 2000 RSI: 2100 RDI: 7f894af88000 RBP: 7f894af88040 R08: 7f894af88040 R09: 2000 R10: R11: 0206 R12: 2000 R13: 2100 R14: 7f894af88000 R15: 20011500 Modules linked in: CR2: ---[ end trace a1b8dbb111baf993 ]--- RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c90008f8fa20 EFLAGS: 00010246 RAX: 113872e8 RBX: dc00 RCX: 0004 RDX: RSI: 88802e9d9490 RDI: 88807f140190 RBP: 89c39740 R08: 81c9d4de R09: fbfff200a946 R10: fbfff200a946 R11: R12: R13: 88807f140190 R14: 111005d3b292 R15: 88802e9d9490 FS: 7f894af88700() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 6bb83000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: BUG: unable to handle kernel NULL pointer dereference in io_uring_cancel_task_requests
On 11/04/2021 09:58, Hao Sun wrote: > Pavel Begunkov 于2021年4月11日周日 下午4:14写道: >> >> On 11/04/2021 04:08, Hao Sun wrote: >>> Hi >>> >>> When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz >>> the Linux kernel, I found a null-ptr-deref bug in >>> io_uring_cancel_task_requests under fault injection condition, but I'm >>> not sure about this. >>> Sorry, I do not have a reproducing program for this bug. >>> I hope that the stack trace information in the crash log can help you >>> locate the problem. >> >> Thanks Hao. io_cqring_wait() fails should not anyhow affect >> cancellation, so the log doesn't make sense from first sight, >> something strange is going on. >> > Is it possible that the failure of io_cqring_wait affects other > operations with side effects between io_cqring_wait and cancellation, > which eventually leads to the cancellation bug? It shouldn't in theory, but need to a look deeper TL;DR; ctx->flags is NULL dereference, means that tctx->xa entry is invalid or file->private got corrupted/not set. Your kernel is old enough (5.11-ish), so it's a bit more safer in that regard and all manipulations with ->xa are pretty much made by the task itself, so should be synchronised. There are things like io_run_task_work() or overflow_flush() that are done in the cqring_wait(), but not much. It also grabs a file beforehand and puts afterwards, extra reference would lead to hangs not such failures. > I found the last call sequence (Syzlang format) executed by the fuzzer > before triggering the bug. > This may be helpful, but there is no guarantee that this is the direct > cause of the bug. appreciate that > > Possible guilty test case: > r19 = syz_io_uring_setup(0x7211, > &(0x7f000540)={0x6e3620b713f86b87,0xf615,0x2,0x1000,0x1a6,0xa26bc79d6b5315eb,0x0,[0x0,0x0,0x0],[0x813a698e7df9790f,0x1,0xb43ab5cc286248ee,0xe543f3b8cf765dd5,0x8005afeb090b0e62,0x1a29b15882d5d0b7,0xd7dc82c17c7ba1a7,0xab9d3c813ad3ae79,0x0,0x0],[0x1,0xd3a439e17ea7133c,0x4b845483eeeab284,0xf6fdf7f35d59044,0xf,0x99a9733bb1278a03,0xf8a69ea77c12e2b2,0x1,0x1,0x176ecee6d3c04836]}, > &(0x7f00/0x5000)=nil, &(0x7f00/0x12)=nil, > &(0x7f0005c0)=0x0, &(0x7f000600)=0x0) > io_uring_enter(r19, 0x1, 0x66ab, 0x3, > &(0x7f40)={[0xfffe8c2bdda0afdd]}, 0x8) > io_uring_register$IORING_UNREGISTER_EVENTFD(r19, 0x5, 0x0, 0x0) > >>> >>> Here is the details: >>> commit: 3b9cdafb5358eb9f3790de2f728f765fef100731 >>> version: linux 5.11 >>> git tree:upstream >>> Full log can be found in the attachment. >>> cqwait() >>> Fault injection log: >>> FAULT_INJECTION: forcing a failure. >>> name fail_usercopy, interval 1, probability 0, space 0, times 0 >>> CPU: 1 PID: 9161 Comm: executor Not tainted 5.11.0+ #5 >>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS >>> rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 >>> Call Trace: >>> __dump_stack lib/dump_stack.c:79 [inline] >>> dump_stack+0x137/0x194 lib/dump_stack.c:120 >>> fail_dump lib/fault-inject.c:52 [inline] >>> should_fail+0x23e/0x250 lib/fault-inject.c:146 >>> should_fail_usercopy+0x16/0x20 lib/fault-inject-usercopy.c:37 >>> _copy_from_user+0x1c/0xd0 lib/usercopy.c:14 >>> copy_from_user include/linux/uaccess.h:192 [inline] >>> set_user_sigmask+0x4b/0x110 kernel/signal.c:3015 >>> io_cqring_wait+0x2e3/0x8b0 fs/io_uring.c:7250 >>> __do_sys_io_uring_enter fs/io_uring.c:9480 [inline] >>> __se_sys_io_uring_enter+0x8fc/0xb70 fs/io_uring.c:9397 >>> __x64_sys_io_uring_enter+0x74/0x80 fs/io_uring.c:9397 >>> do_syscall_64+0x39/0x80 arch/x86/entry/common.c:46 >>> entry_SYSCALL_64_after_hwframe+0x44/0xae >>> RIP: 0033:0x46a379 >>> Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 >>> RSP: 002b:7f046fa19c58 EFLAGS: 0246 ORIG_RAX: 01aa >>> RAX: ffda RBX: 0078c080 RCX: 0046a379 >>> RDX: 66ab RSI: 0001 RDI: 0003 >>> RBP: 7f046fa19c90 R08: 2040 R09: 0008 >>> R10: 0003 R11: 0246 R12: >>> R13: R14: 0078c080 R15: 7fff769deef0 >>> >>> Crash log: >>> BUG: kernel NULL pointer dereference, address: 0040 >>> #PF: supervisor read access in kernel mode >>> #PF: error_code(0x) - not-present page >>> PGD 49954067 P4D 49954067 PUD 45f92067 PMD 0 >>> Oops: [#1] PREEMPT SMP >>> CPU: 1 PID: 9161 Comm: executor Not tainted 5.11.0+ #5 >>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS >>> rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 >>> RIP: 0010:io_uring_cancel_task_requests+0x3f/0x990 fs/io_uring.c:9045 >>> Code: 48 8b 04 25 28 00 00 00 48 89 44 24 68 e8 89 e6 c5 ff 65 4c 8b >>> 34 25 00 6d 01 00 49 8d 7c 24 40 48 89 7c 24 30 e8 81 97 d6 ff <41> 8b >>> 5c 24 40 89 de 83
Re: BUG: unable to handle kernel NULL pointer dereference in io_uring_cancel_task_requests
Pavel Begunkov 于2021年4月11日周日 下午4:14写道: > > On 11/04/2021 04:08, Hao Sun wrote: > > Hi > > > > When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz > > the Linux kernel, I found a null-ptr-deref bug in > > io_uring_cancel_task_requests under fault injection condition, but I'm > > not sure about this. > > Sorry, I do not have a reproducing program for this bug. > > I hope that the stack trace information in the crash log can help you > > locate the problem. > > Thanks Hao. io_cqring_wait() fails should not anyhow affect > cancellation, so the log doesn't make sense from first sight, > something strange is going on. > Is it possible that the failure of io_cqring_wait affects other operations with side effects between io_cqring_wait and cancellation, which eventually leads to the cancellation bug? I found the last call sequence (Syzlang format) executed by the fuzzer before triggering the bug. This may be helpful, but there is no guarantee that this is the direct cause of the bug. Possible guilty test case: r19 = syz_io_uring_setup(0x7211, &(0x7f000540)={0x6e3620b713f86b87,0xf615,0x2,0x1000,0x1a6,0xa26bc79d6b5315eb,0x0,[0x0,0x0,0x0],[0x813a698e7df9790f,0x1,0xb43ab5cc286248ee,0xe543f3b8cf765dd5,0x8005afeb090b0e62,0x1a29b15882d5d0b7,0xd7dc82c17c7ba1a7,0xab9d3c813ad3ae79,0x0,0x0],[0x1,0xd3a439e17ea7133c,0x4b845483eeeab284,0xf6fdf7f35d59044,0xf,0x99a9733bb1278a03,0xf8a69ea77c12e2b2,0x1,0x1,0x176ecee6d3c04836]}, &(0x7f00/0x5000)=nil, &(0x7f00/0x12)=nil, &(0x7f0005c0)=0x0, &(0x7f000600)=0x0) io_uring_enter(r19, 0x1, 0x66ab, 0x3, &(0x7f40)={[0xfffe8c2bdda0afdd]}, 0x8) io_uring_register$IORING_UNREGISTER_EVENTFD(r19, 0x5, 0x0, 0x0) > > > > Here is the details: > > commit: 3b9cdafb5358eb9f3790de2f728f765fef100731 > > version: linux 5.11 > > git tree:upstream > > Full log can be found in the attachment. > > cqwait() > > Fault injection log: > > FAULT_INJECTION: forcing a failure. > > name fail_usercopy, interval 1, probability 0, space 0, times 0 > > CPU: 1 PID: 9161 Comm: executor Not tainted 5.11.0+ #5 > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > > rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 > > Call Trace: > > __dump_stack lib/dump_stack.c:79 [inline] > > dump_stack+0x137/0x194 lib/dump_stack.c:120 > > fail_dump lib/fault-inject.c:52 [inline] > > should_fail+0x23e/0x250 lib/fault-inject.c:146 > > should_fail_usercopy+0x16/0x20 lib/fault-inject-usercopy.c:37 > > _copy_from_user+0x1c/0xd0 lib/usercopy.c:14 > > copy_from_user include/linux/uaccess.h:192 [inline] > > set_user_sigmask+0x4b/0x110 kernel/signal.c:3015 > > io_cqring_wait+0x2e3/0x8b0 fs/io_uring.c:7250 > > __do_sys_io_uring_enter fs/io_uring.c:9480 [inline] > > __se_sys_io_uring_enter+0x8fc/0xb70 fs/io_uring.c:9397 > > __x64_sys_io_uring_enter+0x74/0x80 fs/io_uring.c:9397 > > do_syscall_64+0x39/0x80 arch/x86/entry/common.c:46 > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > RIP: 0033:0x46a379 > > Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > > RSP: 002b:7f046fa19c58 EFLAGS: 0246 ORIG_RAX: 01aa > > RAX: ffda RBX: 0078c080 RCX: 0046a379 > > RDX: 66ab RSI: 0001 RDI: 0003 > > RBP: 7f046fa19c90 R08: 2040 R09: 0008 > > R10: 0003 R11: 0246 R12: > > R13: R14: 0078c080 R15: 7fff769deef0 > > > > Crash log: > > BUG: kernel NULL pointer dereference, address: 0040 > > #PF: supervisor read access in kernel mode > > #PF: error_code(0x) - not-present page > > PGD 49954067 P4D 49954067 PUD 45f92067 PMD 0 > > Oops: [#1] PREEMPT SMP > > CPU: 1 PID: 9161 Comm: executor Not tainted 5.11.0+ #5 > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > > rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 > > RIP: 0010:io_uring_cancel_task_requests+0x3f/0x990 fs/io_uring.c:9045 > > Code: 48 8b 04 25 28 00 00 00 48 89 44 24 68 e8 89 e6 c5 ff 65 4c 8b > > 34 25 00 6d 01 00 49 8d 7c 24 40 48 89 7c 24 30 e8 81 97 d6 ff <41> 8b > > 5c 24 40 89 de 83 e6 02 31 ff e8 70 ea c5 ff 83 e3 02 48 89 > > RSP: 0018:c90002a97b48 EFLAGS: 00010246 > > RAX: 88804b8e0d38 RBX: 88804b8ad700 RCX: 0764 > > RDX: 0040 RSI: 8880409d5140 RDI: 0040 > > RBP: 8880409d5140 R08: R09: 0043 > > R10: 0001 R11: 88804b8e0280 R12: > > R13: 8880409d5140 R14: 88804b8e0280 R15: 8880481c1800 > > FS: 7f046fa1a700() GS:88807ec0() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 0040 CR3: 479a5000 CR4: 00750ee0 > > DR0: 0
Re: BUG: unable to handle kernel NULL pointer dereference in io_uring_cancel_task_requests
On 11/04/2021 04:08, Hao Sun wrote: > Hi > > When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz > the Linux kernel, I found a null-ptr-deref bug in > io_uring_cancel_task_requests under fault injection condition, but I'm > not sure about this. > Sorry, I do not have a reproducing program for this bug. > I hope that the stack trace information in the crash log can help you > locate the problem. Thanks Hao. io_cqring_wait() fails should not anyhow affect cancellation, so the log doesn't make sense from first sight, something strange is going on. > > Here is the details: > commit: 3b9cdafb5358eb9f3790de2f728f765fef100731 > version: linux 5.11 > git tree:upstream > Full log can be found in the attachment. > cqwait() > Fault injection log: > FAULT_INJECTION: forcing a failure. > name fail_usercopy, interval 1, probability 0, space 0, times 0 > CPU: 1 PID: 9161 Comm: executor Not tainted 5.11.0+ #5 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 > Call Trace: > __dump_stack lib/dump_stack.c:79 [inline] > dump_stack+0x137/0x194 lib/dump_stack.c:120 > fail_dump lib/fault-inject.c:52 [inline] > should_fail+0x23e/0x250 lib/fault-inject.c:146 > should_fail_usercopy+0x16/0x20 lib/fault-inject-usercopy.c:37 > _copy_from_user+0x1c/0xd0 lib/usercopy.c:14 > copy_from_user include/linux/uaccess.h:192 [inline] > set_user_sigmask+0x4b/0x110 kernel/signal.c:3015 > io_cqring_wait+0x2e3/0x8b0 fs/io_uring.c:7250 > __do_sys_io_uring_enter fs/io_uring.c:9480 [inline] > __se_sys_io_uring_enter+0x8fc/0xb70 fs/io_uring.c:9397 > __x64_sys_io_uring_enter+0x74/0x80 fs/io_uring.c:9397 > do_syscall_64+0x39/0x80 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x46a379 > Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > RSP: 002b:7f046fa19c58 EFLAGS: 0246 ORIG_RAX: 01aa > RAX: ffda RBX: 0078c080 RCX: 0046a379 > RDX: 66ab RSI: 0001 RDI: 0003 > RBP: 7f046fa19c90 R08: 2040 R09: 0008 > R10: 0003 R11: 0246 R12: > R13: R14: 0078c080 R15: 7fff769deef0 > > Crash log: > BUG: kernel NULL pointer dereference, address: 0040 > #PF: supervisor read access in kernel mode > #PF: error_code(0x) - not-present page > PGD 49954067 P4D 49954067 PUD 45f92067 PMD 0 > Oops: [#1] PREEMPT SMP > CPU: 1 PID: 9161 Comm: executor Not tainted 5.11.0+ #5 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 > RIP: 0010:io_uring_cancel_task_requests+0x3f/0x990 fs/io_uring.c:9045 > Code: 48 8b 04 25 28 00 00 00 48 89 44 24 68 e8 89 e6 c5 ff 65 4c 8b > 34 25 00 6d 01 00 49 8d 7c 24 40 48 89 7c 24 30 e8 81 97 d6 ff <41> 8b > 5c 24 40 89 de 83 e6 02 31 ff e8 70 ea c5 ff 83 e3 02 48 89 > RSP: 0018:c90002a97b48 EFLAGS: 00010246 > RAX: 88804b8e0d38 RBX: 88804b8ad700 RCX: 0764 > RDX: 0040 RSI: 8880409d5140 RDI: 0040 > RBP: 8880409d5140 R08: R09: 0043 > R10: 0001 R11: 88804b8e0280 R12: > R13: 8880409d5140 R14: 88804b8e0280 R15: 8880481c1800 > FS: 7f046fa1a700() GS:88807ec0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 0040 CR3: 479a5000 CR4: 00750ee0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > PKRU: 5554 > Call Trace: > __io_uring_files_cancel+0x9b/0x200 fs/io_uring.c:9140 > io_uring_files_cancel include/linux/io_uring.h:65 [inline] > do_exit+0x1a8/0x16d0 kernel/exit.c:780 > do_group_exit+0xc5/0x180 kernel/exit.c:922 > get_signal+0xd90/0x1470 kernel/signal.c:2773 > arch_do_signal_or_restart+0x2a/0x260 arch/x86/kernel/signal.c:811 > handle_signal_work kernel/entry/common.c:147 [inline] > exit_to_user_mode_loop kernel/entry/common.c:171 [inline] > exit_to_user_mode_prepare+0x109/0x1a0 kernel/entry/common.c:208 > __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline] > syscall_exit_to_user_mode+0x20/0x40 kernel/entry/common.c:301 > do_syscall_64+0x45/0x80 arch/x86/entry/common.c:56 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x46a379 > Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > RSP: 002b:7f046fa19cd8 EFLAGS: 0246 ORIG_RAX: 00ca > RAX: fe00 RBX: 0078c080 RCX: 0046a
BUG: unable to handle kernel NULL pointer dereference in io_uring_cancel_task_requests
Hi When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz the Linux kernel, I found a null-ptr-deref bug in io_uring_cancel_task_requests under fault injection condition, but I'm not sure about this. Sorry, I do not have a reproducing program for this bug. I hope that the stack trace information in the crash log can help you locate the problem. Here is the details: commit: 3b9cdafb5358eb9f3790de2f728f765fef100731 version: linux 5.11 git tree:upstream Full log can be found in the attachment. Fault injection log: FAULT_INJECTION: forcing a failure. name fail_usercopy, interval 1, probability 0, space 0, times 0 CPU: 1 PID: 9161 Comm: executor Not tainted 5.11.0+ #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x137/0x194 lib/dump_stack.c:120 fail_dump lib/fault-inject.c:52 [inline] should_fail+0x23e/0x250 lib/fault-inject.c:146 should_fail_usercopy+0x16/0x20 lib/fault-inject-usercopy.c:37 _copy_from_user+0x1c/0xd0 lib/usercopy.c:14 copy_from_user include/linux/uaccess.h:192 [inline] set_user_sigmask+0x4b/0x110 kernel/signal.c:3015 io_cqring_wait+0x2e3/0x8b0 fs/io_uring.c:7250 __do_sys_io_uring_enter fs/io_uring.c:9480 [inline] __se_sys_io_uring_enter+0x8fc/0xb70 fs/io_uring.c:9397 __x64_sys_io_uring_enter+0x74/0x80 fs/io_uring.c:9397 do_syscall_64+0x39/0x80 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x46a379 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:7f046fa19c58 EFLAGS: 0246 ORIG_RAX: 01aa RAX: ffda RBX: 0078c080 RCX: 0046a379 RDX: 66ab RSI: 0001 RDI: 0003 RBP: 7f046fa19c90 R08: 2040 R09: 0008 R10: 0003 R11: 0246 R12: R13: R14: 0078c080 R15: 7fff769deef0 Crash log: BUG: kernel NULL pointer dereference, address: 0040 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 49954067 P4D 49954067 PUD 45f92067 PMD 0 Oops: [#1] PREEMPT SMP CPU: 1 PID: 9161 Comm: executor Not tainted 5.11.0+ #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:io_uring_cancel_task_requests+0x3f/0x990 fs/io_uring.c:9045 Code: 48 8b 04 25 28 00 00 00 48 89 44 24 68 e8 89 e6 c5 ff 65 4c 8b 34 25 00 6d 01 00 49 8d 7c 24 40 48 89 7c 24 30 e8 81 97 d6 ff <41> 8b 5c 24 40 89 de 83 e6 02 31 ff e8 70 ea c5 ff 83 e3 02 48 89 RSP: 0018:c90002a97b48 EFLAGS: 00010246 RAX: 88804b8e0d38 RBX: 88804b8ad700 RCX: 0764 RDX: 0040 RSI: 8880409d5140 RDI: 0040 RBP: 8880409d5140 R08: R09: 0043 R10: 0001 R11: 88804b8e0280 R12: R13: 8880409d5140 R14: 88804b8e0280 R15: 8880481c1800 FS: 7f046fa1a700() GS:88807ec0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0040 CR3: 479a5000 CR4: 00750ee0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 PKRU: 5554 Call Trace: __io_uring_files_cancel+0x9b/0x200 fs/io_uring.c:9140 io_uring_files_cancel include/linux/io_uring.h:65 [inline] do_exit+0x1a8/0x16d0 kernel/exit.c:780 do_group_exit+0xc5/0x180 kernel/exit.c:922 get_signal+0xd90/0x1470 kernel/signal.c:2773 arch_do_signal_or_restart+0x2a/0x260 arch/x86/kernel/signal.c:811 handle_signal_work kernel/entry/common.c:147 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x109/0x1a0 kernel/entry/common.c:208 __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline] syscall_exit_to_user_mode+0x20/0x40 kernel/entry/common.c:301 do_syscall_64+0x45/0x80 arch/x86/entry/common.c:56 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x46a379 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:7f046fa19cd8 EFLAGS: 0246 ORIG_RAX: 00ca RAX: fe00 RBX: 0078c080 RCX: 0046a379 RDX: RSI: 0080 RDI: 0078c088 RBP: 0078c088 R08: R09: R10: R11: 0246 R12: 0078c08c R13: R14: 0078c080 R15: 7fff769deef0 Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) CR2: 0040 ---[ end trace 613db1a25ecf6
BUG: unable to handle kernel NULL pointer dereference in do_epoll_wait
Hi When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz the Linux kernel, I found a null-ptr-deref bug in do_epoll_wait, but I'm not sure about this. Sorry, I do not have a reproducing program for this bug. I hope that the stack trace information in the crash log can help you locate the problem. Here is the details: commit: 3b9cdafb5358eb9f3790de2f728f765fef100731 version: linux 5.11 git tree:upstream report: BUG: kernel NULL pointer dereference, address: 0048 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 0 P4D 0 Oops: [#1] PREEMPT SMP CPU: 1 PID: 23043 Comm: systemd-udevd Not tainted 5.11.0+ #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:vfs_poll include/linux/poll.h:88 [inline] RIP: 0010:ep_item_poll fs/eventpoll.c:840 [inline] RIP: 0010:ep_send_events fs/eventpoll.c:1677 [inline] RIP: 0010:ep_poll fs/eventpoll.c:1792 [inline] RIP: 0010:do_epoll_wait+0x68d/0xf00 fs/eventpoll.c:2220 Code: 50 89 84 24 d0 00 00 00 48 8d 7b 28 e8 bc 0f d8 ff 48 8b 6b 28 48 c7 c0 e0 6e c6 85 48 39 c5 74 3c 48 8d 7d 48 e8 a3 0f d8 ff <4c> 8b 75 48 4d 85 f6 0f 84 3f 02 00 00 e8 f1 59 c7 ff 48 89 df 48 RSP: 0018:c9000769fdc8 EFLAGS: 00010246 RAX: 88800d87edb8 RBX: 888009b0e600 RCX: 03db RDX: 0048 RSI: RDI: 0048 RBP: R08: R09: 004f R10: 0001 R11: 88800d87e300 R12: 888041f93d18 R13: 888041f93d68 R14: 0004 R15: 888041f93d20 FS: 7f4f3e1fa8c0() GS:88807ec0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0048 CR3: 0e3c5000 CR4: 00750ee0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 PKRU: 5554 Call Trace: __do_sys_epoll_wait fs/eventpoll.c:2232 [inline] __se_sys_epoll_wait fs/eventpoll.c:2227 [inline] __x64_sys_epoll_wait+0xf6/0x120 fs/eventpoll.c:2227 do_syscall_64+0x39/0x80 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f4f3d07b2e3 Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 83 3d 29 54 2b 00 00 75 13 49 89 ca b8 e8 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 0b c2 00 00 48 89 04 24 RSP: 002b:7fff2e5db728 EFLAGS: 0246 ORIG_RAX: 00e8 RAX: ffda RBX: 7fff2e5db7f0 RCX: 7f4f3d07b2e3 RDX: 0004 RSI: 7fff2e5db7f0 RDI: 0004 RBP: 7fff2e5db8a0 R08: 5578feaa7410 R09: 5578fea9b855 R10: R11: 0246 R12: 7fff2e5db7f0 R13: 7fff2e5db7fc R14: 0003 R15: 000e Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) CR2: 0048 ---[ end trace 201f1cc113e7b051 ]--- RIP: 0010:vfs_poll include/linux/poll.h:88 [inline] RIP: 0010:ep_item_poll fs/eventpoll.c:840 [inline] RIP: 0010:ep_send_events fs/eventpoll.c:1677 [inline] RIP: 0010:ep_poll fs/eventpoll.c:1792 [inline] RIP: 0010:do_epoll_wait+0x68d/0xf00 fs/eventpoll.c:2220 Code: 50 89 84 24 d0 00 00 00 48 8d 7b 28 e8 bc 0f d8 ff 48 8b 6b 28 48 c7 c0 e0 6e c6 85 48 39 c5 74 3c 48 8d 7d 48 e8 a3 0f d8 ff <4c> 8b 75 48 4d 85 f6 0f 84 3f 02 00 00 e8 f1 59 c7 ff 48 89 df 48 RSP: 0018:c9000769fdc8 EFLAGS: 00010246 RAX: 88800d87edb8 RBX: 888009b0e600 RCX: 03db RDX: 0048 RSI: RDI: 0048 RBP: R08: R09: 004f R10: 0001 R11: 88800d87e300 R12: 888041f93d18 R13: 888041f93d68 R14: 0004 R15: 888041f93d20 FS: 7f4f3e1fa8c0() GS:88807ec0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0048 CR3: 0e3c5000 CR4: 00750ee0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 PKRU: 5554
Re: [syzbot] BUG: unable to handle kernel NULL pointer dereference in htb_select_queue
On 3/10/21 7:55 PM, Maxim Mikityanskiy wrote: > On 2021-03-10 19:03, Eric Dumazet wrote: >> >> >> On 3/10/21 3:54 PM, Maxim Mikityanskiy wrote: >>> On 2021-03-09 17:20, Eric Dumazet wrote: On 3/9/21 4:13 PM, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: 38b5133a octeontx2-pf: Fix otx2_get_fecparam() > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=166288a8d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=dbc1ca9e55dc1f9f > dashboard link: > https://syzkaller.appspot.com/bug?extid=b53a709f04722ca12a3c > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119454ccd0 > > The issue was bisected to: > > commit d03b195b5aa015f6c11988b86a3625f8d5dbac52 > Author: Maxim Mikityanskiy > Date: Tue Jan 19 12:08:13 2021 + > > sch_htb: Hierarchical QoS hardware offload > > bisection log: > https://syzkaller.appspot.com/x/bisect.txt?x=13ab12ecd0 > final oops: > https://syzkaller.appspot.com/x/report.txt?x=106b12ecd0 > console output: https://syzkaller.appspot.com/x/log.txt?x=17ab12ecd0 > > IMPORTANT: if you fix the issue, please add the following tag to the > commit: > Reported-by: syzbot+b53a709f04722ca12...@syzkaller.appspotmail.com > Fixes: d03b195b5aa0 ("sch_htb: Hierarchical QoS hardware offload") > > BUG: kernel NULL pointer dereference, address: > #PF: supervisor instruction fetch in kernel mode > #PF: error_code(0x0010) - not-present page > PGD 183fe067 P4D 183fe067 PUD 21aef067 PMD 0 > Oops: 0010 [#1] PREEMPT SMP KASAN > CPU: 0 PID: 10125 Comm: syz-executor.0 Not tainted 5.11.0-rc7-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:0x0 > Code: Unable to access opcode bytes at RIP 0xffd6. > RSP: 0018:c9000a9c74e8 EFLAGS: 00010246 > RAX: dc00 RBX: 192001538e9e RCX: > RDX: c9000a9c7520 RSI: 0012 RDI: 88802d158000 > RBP: 88802d158000 R08: fff1 R09: 0400 > R10: 871631c4 R11: R12: 89ea6b40 > R13: dc00 R14: 888012b79c00 R15: > FS: 7f73f9698700() GS:8880b9c0() > knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: ffd6 CR3: 173b5000 CR4: 001506f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > htb_offload net/sched/sch_htb.c:1011 [inline] > htb_select_queue+0x17f/0x2c0 net/sched/sch_htb.c:1349 > tc_modify_qdisc+0x44a/0x1a50 net/sched/sch_api.c:1657 > rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 > netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 > netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] > netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 > netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 > sock_sendmsg_nosec net/socket.c:652 [inline] > sock_sendmsg+0xcf/0x120 net/socket.c:672 > sys_sendmsg+0x6e8/0x810 net/socket.c:2348 > ___sys_sendmsg+0xf3/0x170 net/socket.c:2402 > __sys_sendmsg+0xe5/0x1b0 net/socket.c:2435 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x466019 > Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > RSP: 002b:7f73f9698188 EFLAGS: 0246 ORIG_RAX: 002e > RAX: ffda RBX: 0056bf60 RCX: 00466019 > RDX: RSI: 27c0 RDI: 0004 > RBP: 004bd067 R08: R09: > R10: R11: 0246 R12: 0056bf60 > R13: 7fffefccc11f R14: 7f73f9698300 R15: 00022000 > Modules linked in: > CR2: > ---[ end trace e1544e8206616773 ]--- > RIP: 0010:0x0 > Code: Unable to access opcode bytes at RIP 0xffd6. > RSP: 0018:c9000a9c74e8 EFLAGS: 00010246 > RAX: dc00 RBX: 192001538e9e RCX: > RDX: c9000a9c7520 RSI: 0012 RDI: 88802d158000 > RBP: 88802d158000 R08: fff1 R09: 0400 > R10: 871631c4 R11: R12: 89ea6b40 > R13: dc00 R14: 888012b79c00 R15: > FS: 00
Re: [syzbot] BUG: unable to handle kernel NULL pointer dereference in htb_select_queue
On 2021-03-10 19:03, Eric Dumazet wrote: On 3/10/21 3:54 PM, Maxim Mikityanskiy wrote: On 2021-03-09 17:20, Eric Dumazet wrote: On 3/9/21 4:13 PM, syzbot wrote: Hello, syzbot found the following issue on: HEAD commit: 38b5133a octeontx2-pf: Fix otx2_get_fecparam() git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=166288a8d0 kernel config: https://syzkaller.appspot.com/x/.config?x=dbc1ca9e55dc1f9f dashboard link: https://syzkaller.appspot.com/bug?extid=b53a709f04722ca12a3c syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119454ccd0 The issue was bisected to: commit d03b195b5aa015f6c11988b86a3625f8d5dbac52 Author: Maxim Mikityanskiy Date: Tue Jan 19 12:08:13 2021 + sch_htb: Hierarchical QoS hardware offload bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13ab12ecd0 final oops: https://syzkaller.appspot.com/x/report.txt?x=106b12ecd0 console output: https://syzkaller.appspot.com/x/log.txt?x=17ab12ecd0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+b53a709f04722ca12...@syzkaller.appspotmail.com Fixes: d03b195b5aa0 ("sch_htb: Hierarchical QoS hardware offload") BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 183fe067 P4D 183fe067 PUD 21aef067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 10125 Comm: syz-executor.0 Not tainted 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c9000a9c74e8 EFLAGS: 00010246 RAX: dc00 RBX: 192001538e9e RCX: RDX: c9000a9c7520 RSI: 0012 RDI: 88802d158000 RBP: 88802d158000 R08: fff1 R09: 0400 R10: 871631c4 R11: R12: 89ea6b40 R13: dc00 R14: 888012b79c00 R15: FS: 7f73f9698700() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 173b5000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: htb_offload net/sched/sch_htb.c:1011 [inline] htb_select_queue+0x17f/0x2c0 net/sched/sch_htb.c:1349 tc_modify_qdisc+0x44a/0x1a50 net/sched/sch_api.c:1657 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 sys_sendmsg+0x6e8/0x810 net/socket.c:2348 ___sys_sendmsg+0xf3/0x170 net/socket.c:2402 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2435 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x466019 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:7f73f9698188 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0056bf60 RCX: 00466019 RDX: RSI: 27c0 RDI: 0004 RBP: 004bd067 R08: R09: R10: R11: 0246 R12: 0056bf60 R13: 7fffefccc11f R14: 7f73f9698300 R15: 00022000 Modules linked in: CR2: ---[ end trace e1544e8206616773 ]--- RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c9000a9c74e8 EFLAGS: 00010246 RAX: dc00 RBX: 192001538e9e RCX: RDX: c9000a9c7520 RSI: 0012 RDI: 88802d158000 RBP: 88802d158000 R08: fff1 R09: 0400 R10: 871631c4 R11: R12: 89ea6b40 R13: dc00 R14: 888012b79c00 R15: FS: 7f73f9698700() GS:8880b9d0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 173b5000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot
Re: [syzbot] BUG: unable to handle kernel NULL pointer dereference in htb_select_queue
On 3/10/21 3:54 PM, Maxim Mikityanskiy wrote: > On 2021-03-09 17:20, Eric Dumazet wrote: >> >> >> On 3/9/21 4:13 PM, syzbot wrote: >>> Hello, >>> >>> syzbot found the following issue on: >>> >>> HEAD commit: 38b5133a octeontx2-pf: Fix otx2_get_fecparam() >>> git tree: net-next >>> console output: https://syzkaller.appspot.com/x/log.txt?x=166288a8d0 >>> kernel config: https://syzkaller.appspot.com/x/.config?x=dbc1ca9e55dc1f9f >>> dashboard link: https://syzkaller.appspot.com/bug?extid=b53a709f04722ca12a3c >>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119454ccd0 >>> >>> The issue was bisected to: >>> >>> commit d03b195b5aa015f6c11988b86a3625f8d5dbac52 >>> Author: Maxim Mikityanskiy >>> Date: Tue Jan 19 12:08:13 2021 + >>> >>> sch_htb: Hierarchical QoS hardware offload >>> >>> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13ab12ecd0 >>> final oops: https://syzkaller.appspot.com/x/report.txt?x=106b12ecd0 >>> console output: https://syzkaller.appspot.com/x/log.txt?x=17ab12ecd0 >>> >>> IMPORTANT: if you fix the issue, please add the following tag to the commit: >>> Reported-by: syzbot+b53a709f04722ca12...@syzkaller.appspotmail.com >>> Fixes: d03b195b5aa0 ("sch_htb: Hierarchical QoS hardware offload") >>> >>> BUG: kernel NULL pointer dereference, address: >>> #PF: supervisor instruction fetch in kernel mode >>> #PF: error_code(0x0010) - not-present page >>> PGD 183fe067 P4D 183fe067 PUD 21aef067 PMD 0 >>> Oops: 0010 [#1] PREEMPT SMP KASAN >>> CPU: 0 PID: 10125 Comm: syz-executor.0 Not tainted 5.11.0-rc7-syzkaller #0 >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >>> Google 01/01/2011 >>> RIP: 0010:0x0 >>> Code: Unable to access opcode bytes at RIP 0xffd6. >>> RSP: 0018:c9000a9c74e8 EFLAGS: 00010246 >>> RAX: dc00 RBX: 192001538e9e RCX: >>> RDX: c9000a9c7520 RSI: 0012 RDI: 88802d158000 >>> RBP: 88802d158000 R08: fff1 R09: 0400 >>> R10: 871631c4 R11: R12: 89ea6b40 >>> R13: dc00 R14: 888012b79c00 R15: >>> FS: 7f73f9698700() GS:8880b9c0() knlGS: >>> CS: 0010 DS: ES: CR0: 80050033 >>> CR2: ffd6 CR3: 173b5000 CR4: 001506f0 >>> DR0: DR1: DR2: >>> DR3: DR6: fffe0ff0 DR7: 0400 >>> Call Trace: >>> htb_offload net/sched/sch_htb.c:1011 [inline] >>> htb_select_queue+0x17f/0x2c0 net/sched/sch_htb.c:1349 >>> tc_modify_qdisc+0x44a/0x1a50 net/sched/sch_api.c:1657 >>> rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 >>> netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 >>> netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] >>> netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 >>> netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 >>> sock_sendmsg_nosec net/socket.c:652 [inline] >>> sock_sendmsg+0xcf/0x120 net/socket.c:672 >>> sys_sendmsg+0x6e8/0x810 net/socket.c:2348 >>> ___sys_sendmsg+0xf3/0x170 net/socket.c:2402 >>> __sys_sendmsg+0xe5/0x1b0 net/socket.c:2435 >>> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 >>> entry_SYSCALL_64_after_hwframe+0x44/0xa9 >>> RIP: 0033:0x466019 >>> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 >>> RSP: 002b:7f73f9698188 EFLAGS: 0246 ORIG_RAX: 002e >>> RAX: ffda RBX: 0056bf60 RCX: 00466019 >>> RDX: RSI: 27c0 RDI: 0004 >>> RBP: 004bd067 R08: R09: >>> R10: R11: 0246 R12: 0056bf60 >>> R13: 7fffefccc11f R14: 7f73f9698300 R15: 00022000 >>> Modules linked in: >>> CR2: >>> ---[ end trace e1544e8206616773 ]--- >>> RIP: 0010:0x0 >>> Code: Unable to access opcode bytes at RIP 0xffd6. >>> RSP: 0018:c9000a9c74e8 EFLAGS: 00010246 >>> RAX: dc00 RBX: 192001538e9e RCX: >>> RDX: c9000a9c7520 RSI: 0012 RDI: 88802d158000 >>> RBP: 88802d158000 R08: fff1 R09: 0400 >>> R10: 871631c4 R11: R12: 89ea6b40 >>> R13: dc00 R14: 888012b79c00 R15: >>> FS: 7f73f9698700() GS:8880b9d0() knlGS: >>> CS: 0010 DS: ES: CR0: 80050033 >>> CR2: ffd6 CR3: 173b5000 CR4: 001506e0 >>> DR0: DR1: DR2: >>> DR3: DR6: fffe0ff0 DR7:
Re: [syzbot] BUG: unable to handle kernel NULL pointer dereference in htb_select_queue
On 2021-03-09 17:20, Eric Dumazet wrote: On 3/9/21 4:13 PM, syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:38b5133a octeontx2-pf: Fix otx2_get_fecparam() git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=166288a8d0 kernel config: https://syzkaller.appspot.com/x/.config?x=dbc1ca9e55dc1f9f dashboard link: https://syzkaller.appspot.com/bug?extid=b53a709f04722ca12a3c syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119454ccd0 The issue was bisected to: commit d03b195b5aa015f6c11988b86a3625f8d5dbac52 Author: Maxim Mikityanskiy Date: Tue Jan 19 12:08:13 2021 + sch_htb: Hierarchical QoS hardware offload bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13ab12ecd0 final oops: https://syzkaller.appspot.com/x/report.txt?x=106b12ecd0 console output: https://syzkaller.appspot.com/x/log.txt?x=17ab12ecd0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+b53a709f04722ca12...@syzkaller.appspotmail.com Fixes: d03b195b5aa0 ("sch_htb: Hierarchical QoS hardware offload") BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 183fe067 P4D 183fe067 PUD 21aef067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 10125 Comm: syz-executor.0 Not tainted 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c9000a9c74e8 EFLAGS: 00010246 RAX: dc00 RBX: 192001538e9e RCX: RDX: c9000a9c7520 RSI: 0012 RDI: 88802d158000 RBP: 88802d158000 R08: fff1 R09: 0400 R10: 871631c4 R11: R12: 89ea6b40 R13: dc00 R14: 888012b79c00 R15: FS: 7f73f9698700() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 173b5000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: htb_offload net/sched/sch_htb.c:1011 [inline] htb_select_queue+0x17f/0x2c0 net/sched/sch_htb.c:1349 tc_modify_qdisc+0x44a/0x1a50 net/sched/sch_api.c:1657 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 sys_sendmsg+0x6e8/0x810 net/socket.c:2348 ___sys_sendmsg+0xf3/0x170 net/socket.c:2402 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2435 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x466019 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:7f73f9698188 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0056bf60 RCX: 00466019 RDX: RSI: 27c0 RDI: 0004 RBP: 004bd067 R08: R09: R10: R11: 0246 R12: 0056bf60 R13: 7fffefccc11f R14: 7f73f9698300 R15: 00022000 Modules linked in: CR2: ---[ end trace e1544e8206616773 ]--- RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c9000a9c74e8 EFLAGS: 00010246 RAX: dc00 RBX: 192001538e9e RCX: RDX: c9000a9c7520 RSI: 0012 RDI: 88802d158000 RBP: 88802d158000 R08: fff1 R09: 0400 R10: 871631c4 R11: R12: 89ea6b40 R13: dc00 R14: 888012b79c00 R15: FS: 7f73f9698700() GS:8880b9d0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 173b5000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. For information about bisection process see: https://goo.gl/tpsmEJ#bisection syzbot can test patches for
Re: [syzbot] BUG: unable to handle kernel NULL pointer dereference in htb_select_queue
On 3/9/21 4:13 PM, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:38b5133a octeontx2-pf: Fix otx2_get_fecparam() > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=166288a8d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=dbc1ca9e55dc1f9f > dashboard link: https://syzkaller.appspot.com/bug?extid=b53a709f04722ca12a3c > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119454ccd0 > > The issue was bisected to: > > commit d03b195b5aa015f6c11988b86a3625f8d5dbac52 > Author: Maxim Mikityanskiy > Date: Tue Jan 19 12:08:13 2021 + > > sch_htb: Hierarchical QoS hardware offload > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13ab12ecd0 > final oops: https://syzkaller.appspot.com/x/report.txt?x=106b12ecd0 > console output: https://syzkaller.appspot.com/x/log.txt?x=17ab12ecd0 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+b53a709f04722ca12...@syzkaller.appspotmail.com > Fixes: d03b195b5aa0 ("sch_htb: Hierarchical QoS hardware offload") > > BUG: kernel NULL pointer dereference, address: > #PF: supervisor instruction fetch in kernel mode > #PF: error_code(0x0010) - not-present page > PGD 183fe067 P4D 183fe067 PUD 21aef067 PMD 0 > Oops: 0010 [#1] PREEMPT SMP KASAN > CPU: 0 PID: 10125 Comm: syz-executor.0 Not tainted 5.11.0-rc7-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:0x0 > Code: Unable to access opcode bytes at RIP 0xffd6. > RSP: 0018:c9000a9c74e8 EFLAGS: 00010246 > RAX: dc00 RBX: 192001538e9e RCX: > RDX: c9000a9c7520 RSI: 0012 RDI: 88802d158000 > RBP: 88802d158000 R08: fff1 R09: 0400 > R10: 871631c4 R11: R12: 89ea6b40 > R13: dc00 R14: 888012b79c00 R15: > FS: 7f73f9698700() GS:8880b9c0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: ffd6 CR3: 173b5000 CR4: 001506f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > htb_offload net/sched/sch_htb.c:1011 [inline] > htb_select_queue+0x17f/0x2c0 net/sched/sch_htb.c:1349 > tc_modify_qdisc+0x44a/0x1a50 net/sched/sch_api.c:1657 > rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 > netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 > netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] > netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 > netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 > sock_sendmsg_nosec net/socket.c:652 [inline] > sock_sendmsg+0xcf/0x120 net/socket.c:672 > sys_sendmsg+0x6e8/0x810 net/socket.c:2348 > ___sys_sendmsg+0xf3/0x170 net/socket.c:2402 > __sys_sendmsg+0xe5/0x1b0 net/socket.c:2435 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x466019 > Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 73 > 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > RSP: 002b:7f73f9698188 EFLAGS: 0246 ORIG_RAX: 002e > RAX: ffda RBX: 0056bf60 RCX: 00466019 > RDX: RSI: 27c0 RDI: 0004 > RBP: 004bd067 R08: R09: > R10: R11: 0246 R12: 0056bf60 > R13: 7fffefccc11f R14: 7f73f9698300 R15: 00022000 > Modules linked in: > CR2: > ---[ end trace e1544e8206616773 ]--- > RIP: 0010:0x0 > Code: Unable to access opcode bytes at RIP 0xffd6. > RSP: 0018:c9000a9c74e8 EFLAGS: 00010246 > RAX: dc00 RBX: 192001538e9e RCX: > RDX: c9000a9c7520 RSI: 0012 RDI: 88802d158000 > RBP: 88802d158000 R08: fff1 R09: 0400 > R10: 871631c4 R11: R12: 89ea6b40 > R13: dc00 R14: 888012b79c00 R15: > FS: 7f73f9698700() GS:8880b9d0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: ffd6 CR3: 173b5000 CR4: 001506e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status f
[syzbot] BUG: unable to handle kernel NULL pointer dereference in htb_select_queue
Hello, syzbot found the following issue on: HEAD commit:38b5133a octeontx2-pf: Fix otx2_get_fecparam() git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=166288a8d0 kernel config: https://syzkaller.appspot.com/x/.config?x=dbc1ca9e55dc1f9f dashboard link: https://syzkaller.appspot.com/bug?extid=b53a709f04722ca12a3c syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119454ccd0 The issue was bisected to: commit d03b195b5aa015f6c11988b86a3625f8d5dbac52 Author: Maxim Mikityanskiy Date: Tue Jan 19 12:08:13 2021 + sch_htb: Hierarchical QoS hardware offload bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13ab12ecd0 final oops: https://syzkaller.appspot.com/x/report.txt?x=106b12ecd0 console output: https://syzkaller.appspot.com/x/log.txt?x=17ab12ecd0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+b53a709f04722ca12...@syzkaller.appspotmail.com Fixes: d03b195b5aa0 ("sch_htb: Hierarchical QoS hardware offload") BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 183fe067 P4D 183fe067 PUD 21aef067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 10125 Comm: syz-executor.0 Not tainted 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c9000a9c74e8 EFLAGS: 00010246 RAX: dc00 RBX: 192001538e9e RCX: RDX: c9000a9c7520 RSI: 0012 RDI: 88802d158000 RBP: 88802d158000 R08: fff1 R09: 0400 R10: 871631c4 R11: R12: 89ea6b40 R13: dc00 R14: 888012b79c00 R15: FS: 7f73f9698700() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 173b5000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: htb_offload net/sched/sch_htb.c:1011 [inline] htb_select_queue+0x17f/0x2c0 net/sched/sch_htb.c:1349 tc_modify_qdisc+0x44a/0x1a50 net/sched/sch_api.c:1657 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 sys_sendmsg+0x6e8/0x810 net/socket.c:2348 ___sys_sendmsg+0xf3/0x170 net/socket.c:2402 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2435 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x466019 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:7f73f9698188 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0056bf60 RCX: 00466019 RDX: RSI: 27c0 RDI: 0004 RBP: 004bd067 R08: R09: R10: R11: 0246 R12: 0056bf60 R13: 7fffefccc11f R14: 7f73f9698300 R15: 00022000 Modules linked in: CR2: ---[ end trace e1544e8206616773 ]--- RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c9000a9c74e8 EFLAGS: 00010246 RAX: dc00 RBX: 192001538e9e RCX: RDX: c9000a9c7520 RSI: 0012 RDI: 88802d158000 RBP: 88802d158000 R08: fff1 R09: 0400 R10: 871631c4 R11: R12: 89ea6b40 R13: dc00 R14: 888012b79c00 R15: FS: 7f73f9698700() GS:8880b9d0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 173b5000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. For information about bisection process see: https://goo.gl/tpsmEJ#bisection syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
BUG: unable to handle kernel NULL pointer dereference in hide_cursor
Hello, syzbot found the following issue on: HEAD commit:5695e516 Merge tag 'io_uring-worker.v3-2021-02-25' of git:.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=10bc7b96d0 kernel config: https://syzkaller.appspot.com/x/.config?x=e33ab2de74f48295 dashboard link: https://syzkaller.appspot.com/bug?extid=e28df1dcd2038f11d0f1 compiler: Debian clang version 11.0.1-2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=145911b0d0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16123ff2d0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e28df1dcd2038f11d...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 12e8c067 P4D 12e8c067 PUD 242de067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 8335 Comm: syz-executor258 Not tainted 5.11.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c9000dcf7aa8 EFLAGS: 00010286 RAX: RBX: 8a151c78 RCX: 0007 RDX: 0002 RSI: 888143df RDI: 888010879000 RBP: dc00 R08: R09: 84048b55 R10: 0002 R11: 88801b115340 R12: dc00 R13: 11100210f27c R14: 8880108793e0 R15: 888010879000 FS: 00e5a300() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 11d74000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: hide_cursor+0x7e/0x310 drivers/tty/vt/vt.c:907 redraw_screen+0x190/0x11a0 drivers/tty/vt/vt.c:1012 vc_do_resize+0x1178/0x1780 drivers/tty/vt/vt.c:1325 fbcon_set_disp+0x9f2/0xf90 drivers/video/fbdev/core/fbcon.c:1402 con2fb_init_display drivers/video/fbdev/core/fbcon.c:808 [inline] set_con2fb_map+0x7f6/0xe90 drivers/video/fbdev/core/fbcon.c:879 fbcon_set_con2fb_map_ioctl+0x19e/0x280 drivers/video/fbdev/core/fbcon.c:3010 do_fb_ioctl+0x307/0x6e0 drivers/video/fbdev/core/fbmem.c:1156 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x43eed9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 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 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:7ffd3f7a18c8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 00400488 RCX: 0043eed9 RDX: 2040 RSI: 4610 RDI: 0004 RBP: 00402ec0 R08: 00400488 R09: 00400488 R10: 00400488 R11: 0246 R12: 00402f50 R13: R14: 004ac018 R15: 00400488 Modules linked in: CR2: ---[ end trace 867c96c33860cda9 ]--- RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c9000dcf7aa8 EFLAGS: 00010286 RAX: RBX: 8a151c78 RCX: 0007 RDX: 0002 RSI: 888143df RDI: 888010879000 RBP: dc00 R08: R09: 84048b55 R10: 0002 R11: 88801b115340 R12: dc00 R13: 11100210f27c R14: 8880108793e0 R15: 888010879000 FS: 00e5a300() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 11d74000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: BUG: unable to handle kernel NULL pointer dereference in call_rcu
On Wed, Feb 24, 2021 at 1:58 PM syzbot wrote: > > syzbot has bisected this issue to: > > commit 97593cad003c668e2532cb2939a24a031f8de52d > Author: Andrey Konovalov > Date: Tue Dec 22 20:03:28 2020 + > > kasan: sanitize objects when metadata doesn't fit > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=106689b6d0 > start commit: 614cb589 Merge tag 'acpi-5.11-rc1-2' of git://git.kernel.o.. > git tree: upstream > final oops: https://syzkaller.appspot.com/x/report.txt?x=126689b6d0 > console output: https://syzkaller.appspot.com/x/log.txt?x=146689b6d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=bf519e1e96191576 > dashboard link: https://syzkaller.appspot.com/bug?extid=9d3ede723bdc58553f13 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11830e9350 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13d9205750 > > Reported-by: syzbot+9d3ede723bdc58553...@syzkaller.appspotmail.com > Fixes: 97593cad003c ("kasan: sanitize objects when metadata doesn't fit") > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection #syz fix: kasan: fix null pointer dereference in kasan_record_aux_stack
Re: BUG: unable to handle kernel NULL pointer dereference in call_rcu
syzbot has bisected this issue to: commit 97593cad003c668e2532cb2939a24a031f8de52d Author: Andrey Konovalov Date: Tue Dec 22 20:03:28 2020 + kasan: sanitize objects when metadata doesn't fit bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=106689b6d0 start commit: 614cb589 Merge tag 'acpi-5.11-rc1-2' of git://git.kernel.o.. git tree: upstream final oops: https://syzkaller.appspot.com/x/report.txt?x=126689b6d0 console output: https://syzkaller.appspot.com/x/log.txt?x=146689b6d0 kernel config: https://syzkaller.appspot.com/x/.config?x=bf519e1e96191576 dashboard link: https://syzkaller.appspot.com/bug?extid=9d3ede723bdc58553f13 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11830e9350 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13d9205750 Reported-by: syzbot+9d3ede723bdc58553...@syzkaller.appspotmail.com Fixes: 97593cad003c ("kasan: sanitize objects when metadata doesn't fit") For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[next] Unable to handle kernel NULL pointer dereference at - pc : gpiodevice_release
While running kselftest gpio mockup test case on qualcomm dragonboard 410c the following kernel crash reported on Linux next tag 20210203. # selftests: gpio: gpio-mockup.sh # 1. Module load tests # 1.1. dynamic allocation of gpio # ./gpio-mockup.sh: line 106: ./gpio-mockup-cdev: No such file or directory # test failed: line value is 127 when 1 was expected # GPIO gpio-mockup test FAIL [ 124.539778] Unable to handle kernel NULL pointer dereference at virtual address 05a8 [ 124.539864] Mem abort info: [ 124.547998] ESR = 0x9606 [ 124.550188] EC = 0x25: DABT (current EL), IL = 32 bits [ 124.553473] SET = 0, FnV = 0 [ 124.558926] EA = 0, S1PTW = 0 [ 124.561646] Data abort info: [ 124.564863] ISV = 0, ISS = 0x0006 [ 124.567933] CM = 0, WnR = 0 [ 124.571507] user pgtable: 4k pages, 48-bit VAs, pgdp=8b721000 [ 124.574694] [05a8] pgd=91cd2003, p4d=91cd2003, pud=917ac003, pmd= [ 124.581396] Internal error: Oops: 9606 [#1] PREEMPT SMP [ 124.591499] Modules linked in: gpio_mockup(-) snd_soc_hdmi_codec adv7511 cec rfkill snd_soc_msm8916_analog qcom_spmi_temp_alarm qcom_pon rtc_pm8xxx msm snd_soc_lpass_apq8016 snd_soc_lpass_cpu snd_soc_lpass_platform snd_soc_msm8916_digital qcom_camss videobuf2_dma_sg snd_soc_apq8016_sbc v4l2_fwnode snd_soc_qcom_common videobuf2_memops videobuf2_v4l2 mdt_loader videobuf2_common drm_kms_helper qnoc_msm8916 qcom_rng i2c_qcom_cci icc_smd_rpm crct10dif_ce socinfo rmtfs_mem display_connector drm qrtr ns fuse [ 124.619092] CPU: 0 PID: 5055 Comm: modprobe Not tainted 5.11.0-rc6-next-20210203 #1 [ 124.641324] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 124.648877] pstate: 8005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 124.655819] pc : gpiodevice_release+0x38/0x80 [ 124.661806] lr : device_release+0x3c/0x98 [ 124.666058] sp : 800013f23b30 [ 124.670051] x29: 800013f23b30 x28: 157baf80 [ 124.673351] x27: x26: [ 124.678734] x25: 0045 x24: 0b5d6cd0 [ 124.684029] x23: 800013f23c88 x22: [ 124.689324] x21: 0fb5f080 x20: 02334e00 [ 124.694619] x19: x18: 800012dd6a50 [ 124.699914] x17: x16: [ 124.705210] x15: 000694e0 x14: [ 124.710512] x13: 0001 x12: e107 [ 124.715799] x11: e10a x10: 800012d34a50 [ 124.721096] x9 : 80001344a000 x8 : 512c1926 [ 124.726391] x7 : 0cb44760 x6 : 800013f23a40 [ 124.731685] x5 : dead0100 x4 : dead0122 [ 124.736981] x3 : 800012891000 x2 : 2be62a0e7519e400 [ 124.742275] x1 : 800010829ad0 x0 : 800012a694e0 [ 124.747571] Call trace: [ 124.752862] gpiodevice_release+0x38/0x80 [ 124.755035] device_release+0x3c/0x98 [ 124.759201] kobject_put+0x90/0x220 [ 124.762846] put_device+0x24/0x30 [ 124.766145] gpiochip_remove+0xf4/0x120 [ 124.769618] devm_gpio_chip_release+0x20/0x30 [ 124.773263] devm_action_release+0x20/0x30 [ 124.77] release_nodes+0x150/0x248 [ 124.781771] devres_release_all+0x3c/0x60 [ 124.785503] device_release_driver_internal+0x128/0x1f0 [ 124.789584] driver_detach+0x5c/0xe8 [ 124.794618] bus_remove_driver+0x64/0x118 [ 124.798439] driver_unregister+0x34/0x60 [ 124.802344] platform_driver_unregister+0x20/0x30 [ 124.806339] gpio_mockup_exit+0x30/0x3d0 [gpio_mockup] [ 124.810939] __arm64_sys_delete_module+0x1c8/0x2b8 [ 124.815973] el0_svc_common+0x88/0x1b8 [ 124.820745] do_el0_svc+0x38/0x90 [ 124.824478] el0_svc+0x1c/0x28 [ 124.827864] el0_sync_handler+0x8c/0xb0 [ 124.830815] el0_sync+0x13c/0x140 [ 124.834555] Code: f2fbd5a4 90011200 91124000 91014000 (f942d663) [ 124.838029] ---[ end trace 15e9a0840604e538 ]--- Reported-by: Naresh Kamboju full test log link, https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20210203/testrun/3878290/suite/linux-log-parser/test/check-kernel-oops-2224485/log metadata: git branch: master git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git git describe: next-20210203 kernel-config: http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/dragonboard-410c/lkft/linux-next/952/config build: http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/dragonboard-410c/lkft/linux-next/952/ vmlinux: http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/dragonboard-410c/lkft/linux-next/952/vmlinux -- Linaro LKFT https://lkft.linaro.org
Re: BUG: unable to handle kernel NULL pointer dereference in fbcon_cursor
On Sun, Jan 17, 2021 at 03:29:05AM -0800, syzbot wrote: > syzbot has bisected this issue to: > > commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2 > Author: Daniel Vetter > Date: Fri Oct 9 23:21:56 2020 + > > drm/vkms: fbdev emulation support Not sure you want to annotate this, but this just makes the bug reproducible on vkms. It's a preexisting issue (probably a few decades old) of the fbcon code afaict. It might also be that you can only repro this when you have multiple fbcon drivers (vkms plus whatever your virtual machine has I guess). -Daniel > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=148e2748d0 > start commit: b3a3cbde Add linux-next specific files for 20210115 > git tree: linux-next > final oops: https://syzkaller.appspot.com/x/report.txt?x=168e2748d0 > console output: https://syzkaller.appspot.com/x/log.txt?x=128e2748d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=6ea08dae6aab586f > dashboard link: https://syzkaller.appspot.com/bug?extid=b67aaae8d3a927f68d20 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15cd8fe0d0 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17af5258d0 > > Reported-by: syzbot+b67aaae8d3a927f68...@syzkaller.appspotmail.com > Fixes: ea40d7857d52 ("drm/vkms: fbdev emulation support") > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: BUG: unable to handle kernel NULL pointer dereference in fbcon_cursor
syzbot has bisected this issue to: commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2 Author: Daniel Vetter Date: Fri Oct 9 23:21:56 2020 + drm/vkms: fbdev emulation support bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=148e2748d0 start commit: b3a3cbde Add linux-next specific files for 20210115 git tree: linux-next final oops: https://syzkaller.appspot.com/x/report.txt?x=168e2748d0 console output: https://syzkaller.appspot.com/x/log.txt?x=128e2748d0 kernel config: https://syzkaller.appspot.com/x/.config?x=6ea08dae6aab586f dashboard link: https://syzkaller.appspot.com/bug?extid=b67aaae8d3a927f68d20 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15cd8fe0d0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17af5258d0 Reported-by: syzbot+b67aaae8d3a927f68...@syzkaller.appspotmail.com Fixes: ea40d7857d52 ("drm/vkms: fbdev emulation support") For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: BUG: unable to handle kernel NULL pointer dereference in fbcon_cursor
syzbot has found a reproducer for the following issue on: HEAD commit:b3a3cbde Add linux-next specific files for 20210115 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=164096d750 kernel config: https://syzkaller.appspot.com/x/.config?x=6ea08dae6aab586f dashboard link: https://syzkaller.appspot.com/bug?extid=b67aaae8d3a927f68d20 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15cd8fe0d0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17af5258d0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+b67aaae8d3a927f68...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 12267067 P4D 12267067 PUD 11841067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8463 Comm: syz-executor088 Not tainted 5.11.0-rc3-next-20210115-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c9000132f850 EFLAGS: 00010292 RAX: 0007 RBX: RCX: 0007 RDX: 0002 RSI: 88814394b000 RDI: 888010071000 RBP: 888010071000 R08: R09: 83ed87ea R10: 0003 R11: 0018 R12: 88814394b000 R13: R14: R15: 0720 FS: 00db8880() GS:8880b9f0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 20cd8000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: fbcon_cursor+0x50e/0x620 drivers/video/fbdev/core/fbcon.c:1336 hide_cursor+0x85/0x280 drivers/tty/vt/vt.c:907 redraw_screen+0x5b4/0x740 drivers/tty/vt/vt.c:1012 vc_do_resize+0xed8/0x1150 drivers/tty/vt/vt.c:1325 fbcon_set_disp+0x7a8/0xe10 drivers/video/fbdev/core/fbcon.c:1402 con2fb_init_display drivers/video/fbdev/core/fbcon.c:808 [inline] set_con2fb_map+0x7a6/0xf80 drivers/video/fbdev/core/fbcon.c:879 fbcon_set_con2fb_map_ioctl+0x165/0x220 drivers/video/fbdev/core/fbcon.c:3010 do_fb_ioctl+0x5b6/0x690 drivers/video/fbdev/core/fbmem.c:1156 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1185 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x4402b9 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:7ae24f88 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 004002c8 RCX: 004402b9 RDX: 2080 RSI: 4610 RDI: 0004 RBP: 006ca018 R08: 004002c8 R09: 004002c8 R10: 004002c8 R11: 0246 R12: 00401ac0 R13: 00401b50 R14: R15: Modules linked in: CR2: ---[ end trace 5adb9f198fe5efa6 ]--- RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c9000132f850 EFLAGS: 00010292 RAX: 0007 RBX: RCX: 0007 RDX: 0002 RSI: 88814394b000 RDI: 888010071000 RBP: 888010071000 R08: R09: 83ed87ea R10: 0003 R11: 0018 R12: 88814394b000 R13: R14: R15: 0720 FS: 00db8880() GS:8880b9f0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 20cd8000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400
Re: BUG: unable to handle kernel NULL pointer dereference in __lookup_slow
On Sat, Jan 9, 2021 at 8:20 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit d24396c5290ba8ab04ba505176874c4e04a2d53c > Author: Rustam Kovhaev > Date: Sun Nov 1 14:09:58 2020 + > > reiserfs: add check for an invalid ih_entry_count > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=111480e750 > start commit: a68a0262 mm/madvise: remove racy mm ownership check > git tree: upstream > kernel config: https://syzkaller.appspot.com/x/.config?x=e597c2b53c984cd8 > dashboard link: https://syzkaller.appspot.com/bug?extid=3db80bbf66b88d68af9d > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1737b8a750 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1697246b50 > > If the result looks correct, please mark the issue as fixed by replying with: > > #syz fix: reiserfs: add check for an invalid ih_entry_count > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection Looks realistic. #syz fix: reiserfs: add check for an invalid ih_entry_count
Re: BUG: unable to handle kernel NULL pointer dereference in __lookup_slow
syzbot suspects this issue was fixed by commit: commit d24396c5290ba8ab04ba505176874c4e04a2d53c Author: Rustam Kovhaev Date: Sun Nov 1 14:09:58 2020 + reiserfs: add check for an invalid ih_entry_count bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=111480e750 start commit: a68a0262 mm/madvise: remove racy mm ownership check git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=e597c2b53c984cd8 dashboard link: https://syzkaller.appspot.com/bug?extid=3db80bbf66b88d68af9d syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1737b8a750 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1697246b50 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: reiserfs: add check for an invalid ih_entry_count For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: BUG: unable to handle kernel NULL pointer dereference in call_rcu
On Sun, 2020-12-27 at 20:51 +0100, Dmitry Vyukov wrote: > /\/\/\/\On Sun, Dec 27, 2020 at 8:45 PM Andrew Morton > wrote: > > > > (cc KASAN developers) > > > > On Sat, 26 Dec 2020 15:25:14 -0800 syzbot > > wrote: > > > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit:614cb589 Merge tag 'acpi-5.11-rc1-2' of > > > git://git.kernel.o.. > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=10a82a50d0 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=bf519e1e96191576 > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=9d3ede723bdc58553f13 > > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11830e9350 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13d9205750 > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the > > > commit: > > > Reported-by: syzbot+9d3ede723bdc58553...@syzkaller.appspotmail.com > > > > > > BUG: kernel NULL pointer dereference, address: 0008 > > > #PF: supervisor read access in kernel mode > > > #PF: error_code(0x) - not-present page > > > PGD 2d993067 P4D 2d993067 PUD 19a3c067 PMD 0 > > > Oops: [#1] PREEMPT SMP KASAN > > > CPU: 1 PID: 3852 Comm: kworker/1:2 Not tainted 5.10.0-syzkaller #0 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > > Google 01/01/2011 > > > Workqueue: events free_ipc > > > RIP: 0010:kasan_record_aux_stack+0x77/0xb0 mm/kasan/generic.c:341 > > +Walter, Andrey > > void kasan_record_aux_stack(void *addr) > { > ... > alloc_meta = kasan_get_alloc_meta(cache, object); > alloc_meta->aux_stack[1] = alloc_meta->aux_stack[0]; > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > It crashes on NULL deref here, I assume alloc_meta is NULL. We may not > have it for some slabs. Do we miss a NULL check here? > Hi Dmitry, Yes, I will send a patch to fix it. Thanks for your suggestion. Walter > > > > > > Code: 48 f7 fe 8b 47 24 49 89 f0 48 29 d3 8d 70 ff 41 0f af f0 48 01 ce > > > 48 39 f3 48 0f 46 f3 e8 81 e9 ff ff bf 00 08 00 00 48 89 c3 <8b> 40 08 89 > > > 43 0c e8 1e e6 ff ff 89 43 08 5b c3 48 8b 50 08 48 c7 > > > RSP: 0018:c90002e6fae8 EFLAGS: 00010046 > > > RAX: RBX: RCX: 88803980 > > > RDX: 0078 RSI: 88803980 RDI: 0800 > > > RBP: 837ef3a0 R08: 0040 R09: 002e > > > R10: 8132b7ea R11: 003f R12: 00035b40 > > > R13: 888039800088 R14: c90002e6fc08 R15: 0200 > > > FS: () GS:8880b9d0() > > > knlGS: > > > CS: 0010 DS: ES: CR0: 80050033 > > > CR2: 0008 CR3: 11841000 CR4: 001506e0 > > > DR0: DR1: DR2: > > > DR3: DR6: fffe0ff0 DR7: 0400 > > > Call Trace: > > > __call_rcu kernel/rcu/tree.c:2965 [inline] > > > call_rcu+0xbb/0x710 kernel/rcu/tree.c:3038 > > > ipc_rcu_putref+0x83/0xb0 ipc/util.c:505 > > > freeary+0x139c/0x1b30 ipc/sem.c:1188 > > > free_ipcs+0x98/0x1e0 ipc/namespace.c:112 > > > sem_exit_ns+0x1b/0x40 ipc/sem.c:260 > > > free_ipc_ns ipc/namespace.c:124 [inline] > > > free_ipc+0xf8/0x200 ipc/namespace.c:141 > > > process_one_work+0x98d/0x1630 kernel/workqueue.c:2275 > > > worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 > > > kthread+0x3b1/0x4a0 kernel/kthread.c:292 > > > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 > > > Modules linked in: > > > CR2: 0008 > > > ---[ end trace 28dc093e61d44dc2 ]--- > > > RIP: 0010:kasan_record_aux_stack+0x77/0xb0 mm/kasan/generic.c:341 > > > Code: 48 f7 fe 8b 47 24 49 89 f0 48 29 d3 8d 70 ff 41 0f af f0 48 01 ce > > > 48 39 f3 48 0f 46 f3 e8 81 e9 ff ff bf 00 08 00 00 48 89 c3 <8b> 40 08 89 > > > 43 0c e8 1e e6 ff ff 89 43 08 5b c3 48 8b 50 08 48 c7 > > > RSP: 0018:c90002e6fae8 EFLAGS: 00010046 > > > RAX: RBX: RCX: 88803980 > > > RDX: 0078 RSI: 88803980 RDI: 0800 > > > RBP: 837ef3a0 R08: 0040 R09: 002e > > > R10: 8132b7ea R11: 003f R12: 00035b40 > > > R13: 888039800088 R14: c90002e6fc08 R15: 0200 > > > FS: () GS:8880b9d0() > > > knlGS: > > > CS: 0010 DS: ES: CR0: 80050033 > > > CR2: 0008 CR3: 11841000 CR4: 001506e0 > > > DR0: DR1: DR2: > > > DR3: DR6: fffe0ff0 DR7: 0400 > > > > > > > > > --- > > > This report is generated by a bot. It may contain errors. > > > See https://goo.gl/tpsmEJ for more information about syzbot. > > > syzbot e
Re: BUG: unable to handle kernel NULL pointer dereference in call_rcu
/\/\/\/\On Sun, Dec 27, 2020 at 8:45 PM Andrew Morton wrote: > > (cc KASAN developers) > > On Sat, 26 Dec 2020 15:25:14 -0800 syzbot > wrote: > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:614cb589 Merge tag 'acpi-5.11-rc1-2' of git://git.kernel.o.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=10a82a50d0 > > kernel config: https://syzkaller.appspot.com/x/.config?x=bf519e1e96191576 > > dashboard link: https://syzkaller.appspot.com/bug?extid=9d3ede723bdc58553f13 > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11830e9350 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13d9205750 > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+9d3ede723bdc58553...@syzkaller.appspotmail.com > > > > BUG: kernel NULL pointer dereference, address: 0008 > > #PF: supervisor read access in kernel mode > > #PF: error_code(0x) - not-present page > > PGD 2d993067 P4D 2d993067 PUD 19a3c067 PMD 0 > > Oops: [#1] PREEMPT SMP KASAN > > CPU: 1 PID: 3852 Comm: kworker/1:2 Not tainted 5.10.0-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > Workqueue: events free_ipc > > RIP: 0010:kasan_record_aux_stack+0x77/0xb0 mm/kasan/generic.c:341 +Walter, Andrey void kasan_record_aux_stack(void *addr) { ... alloc_meta = kasan_get_alloc_meta(cache, object); alloc_meta->aux_stack[1] = alloc_meta->aux_stack[0]; /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ It crashes on NULL deref here, I assume alloc_meta is NULL. We may not have it for some slabs. Do we miss a NULL check here? > > Code: 48 f7 fe 8b 47 24 49 89 f0 48 29 d3 8d 70 ff 41 0f af f0 48 01 ce 48 > > 39 f3 48 0f 46 f3 e8 81 e9 ff ff bf 00 08 00 00 48 89 c3 <8b> 40 08 89 43 > > 0c e8 1e e6 ff ff 89 43 08 5b c3 48 8b 50 08 48 c7 > > RSP: 0018:c90002e6fae8 EFLAGS: 00010046 > > RAX: RBX: RCX: 88803980 > > RDX: 0078 RSI: 88803980 RDI: 0800 > > RBP: 837ef3a0 R08: 0040 R09: 002e > > R10: 8132b7ea R11: 003f R12: 00035b40 > > R13: 888039800088 R14: c90002e6fc08 R15: 0200 > > FS: () GS:8880b9d0() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 0008 CR3: 11841000 CR4: 001506e0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > Call Trace: > > __call_rcu kernel/rcu/tree.c:2965 [inline] > > call_rcu+0xbb/0x710 kernel/rcu/tree.c:3038 > > ipc_rcu_putref+0x83/0xb0 ipc/util.c:505 > > freeary+0x139c/0x1b30 ipc/sem.c:1188 > > free_ipcs+0x98/0x1e0 ipc/namespace.c:112 > > sem_exit_ns+0x1b/0x40 ipc/sem.c:260 > > free_ipc_ns ipc/namespace.c:124 [inline] > > free_ipc+0xf8/0x200 ipc/namespace.c:141 > > process_one_work+0x98d/0x1630 kernel/workqueue.c:2275 > > worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 > > kthread+0x3b1/0x4a0 kernel/kthread.c:292 > > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 > > Modules linked in: > > CR2: 0008 > > ---[ end trace 28dc093e61d44dc2 ]--- > > RIP: 0010:kasan_record_aux_stack+0x77/0xb0 mm/kasan/generic.c:341 > > Code: 48 f7 fe 8b 47 24 49 89 f0 48 29 d3 8d 70 ff 41 0f af f0 48 01 ce 48 > > 39 f3 48 0f 46 f3 e8 81 e9 ff ff bf 00 08 00 00 48 89 c3 <8b> 40 08 89 43 > > 0c e8 1e e6 ff ff 89 43 08 5b c3 48 8b 50 08 48 c7 > > RSP: 0018:c90002e6fae8 EFLAGS: 00010046 > > RAX: RBX: RCX: 88803980 > > RDX: 0078 RSI: 88803980 RDI: 0800 > > RBP: 837ef3a0 R08: 0040 R09: 002e > > R10: 8132b7ea R11: 003f R12: 00035b40 > > R13: 888039800088 R14: c90002e6fc08 R15: 0200 > > FS: () GS:8880b9d0() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 0008 CR3: 11841000 CR4: 001506e0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > > > > > --- > > This report is generated by a bot. It may contain errors. > > See https://goo.gl/tpsmEJ for more information about syzbot. > > syzbot engineers can be reached at syzkal...@googlegroups.com. > > > > syzbot will keep track of this issue. See: > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > syzbot can test patches for this issue, for details see: > > https://goo.gl/tpsmEJ#testing-patches
Re: BUG: unable to handle kernel NULL pointer dereference in call_rcu
(cc KASAN developers) On Sat, 26 Dec 2020 15:25:14 -0800 syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:614cb589 Merge tag 'acpi-5.11-rc1-2' of git://git.kernel.o.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=10a82a50d0 > kernel config: https://syzkaller.appspot.com/x/.config?x=bf519e1e96191576 > dashboard link: https://syzkaller.appspot.com/bug?extid=9d3ede723bdc58553f13 > compiler: gcc (GCC) 10.1.0-syz 20200507 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11830e9350 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13d9205750 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+9d3ede723bdc58553...@syzkaller.appspotmail.com > > BUG: kernel NULL pointer dereference, address: 0008 > #PF: supervisor read access in kernel mode > #PF: error_code(0x) - not-present page > PGD 2d993067 P4D 2d993067 PUD 19a3c067 PMD 0 > Oops: [#1] PREEMPT SMP KASAN > CPU: 1 PID: 3852 Comm: kworker/1:2 Not tainted 5.10.0-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Workqueue: events free_ipc > RIP: 0010:kasan_record_aux_stack+0x77/0xb0 mm/kasan/generic.c:341 > Code: 48 f7 fe 8b 47 24 49 89 f0 48 29 d3 8d 70 ff 41 0f af f0 48 01 ce 48 39 > f3 48 0f 46 f3 e8 81 e9 ff ff bf 00 08 00 00 48 89 c3 <8b> 40 08 89 43 0c e8 > 1e e6 ff ff 89 43 08 5b c3 48 8b 50 08 48 c7 > RSP: 0018:c90002e6fae8 EFLAGS: 00010046 > RAX: RBX: RCX: 88803980 > RDX: 0078 RSI: 88803980 RDI: 0800 > RBP: 837ef3a0 R08: 0040 R09: 002e > R10: 8132b7ea R11: 003f R12: 00035b40 > R13: 888039800088 R14: c90002e6fc08 R15: 0200 > FS: () GS:8880b9d0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 0008 CR3: 11841000 CR4: 001506e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > __call_rcu kernel/rcu/tree.c:2965 [inline] > call_rcu+0xbb/0x710 kernel/rcu/tree.c:3038 > ipc_rcu_putref+0x83/0xb0 ipc/util.c:505 > freeary+0x139c/0x1b30 ipc/sem.c:1188 > free_ipcs+0x98/0x1e0 ipc/namespace.c:112 > sem_exit_ns+0x1b/0x40 ipc/sem.c:260 > free_ipc_ns ipc/namespace.c:124 [inline] > free_ipc+0xf8/0x200 ipc/namespace.c:141 > process_one_work+0x98d/0x1630 kernel/workqueue.c:2275 > worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 > kthread+0x3b1/0x4a0 kernel/kthread.c:292 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 > Modules linked in: > CR2: 0008 > ---[ end trace 28dc093e61d44dc2 ]--- > RIP: 0010:kasan_record_aux_stack+0x77/0xb0 mm/kasan/generic.c:341 > Code: 48 f7 fe 8b 47 24 49 89 f0 48 29 d3 8d 70 ff 41 0f af f0 48 01 ce 48 39 > f3 48 0f 46 f3 e8 81 e9 ff ff bf 00 08 00 00 48 89 c3 <8b> 40 08 89 43 0c e8 > 1e e6 ff ff 89 43 08 5b c3 48 8b 50 08 48 c7 > RSP: 0018:c90002e6fae8 EFLAGS: 00010046 > RAX: RBX: RCX: 88803980 > RDX: 0078 RSI: 88803980 RDI: 0800 > RBP: 837ef3a0 R08: 0040 R09: 002e > R10: 8132b7ea R11: 003f R12: 00035b40 > R13: 888039800088 R14: c90002e6fc08 R15: 0200 > FS: () GS:8880b9d0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 0008 CR3: 11841000 CR4: 001506e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > syzbot can test patches for this issue, for details see: > https://goo.gl/tpsmEJ#testing-patches
BUG: unable to handle kernel NULL pointer dereference in call_rcu
Hello, syzbot found the following issue on: HEAD commit:614cb589 Merge tag 'acpi-5.11-rc1-2' of git://git.kernel.o.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=10a82a50d0 kernel config: https://syzkaller.appspot.com/x/.config?x=bf519e1e96191576 dashboard link: https://syzkaller.appspot.com/bug?extid=9d3ede723bdc58553f13 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11830e9350 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13d9205750 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+9d3ede723bdc58553...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: 0008 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 2d993067 P4D 2d993067 PUD 19a3c067 PMD 0 Oops: [#1] PREEMPT SMP KASAN CPU: 1 PID: 3852 Comm: kworker/1:2 Not tainted 5.10.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events free_ipc RIP: 0010:kasan_record_aux_stack+0x77/0xb0 mm/kasan/generic.c:341 Code: 48 f7 fe 8b 47 24 49 89 f0 48 29 d3 8d 70 ff 41 0f af f0 48 01 ce 48 39 f3 48 0f 46 f3 e8 81 e9 ff ff bf 00 08 00 00 48 89 c3 <8b> 40 08 89 43 0c e8 1e e6 ff ff 89 43 08 5b c3 48 8b 50 08 48 c7 RSP: 0018:c90002e6fae8 EFLAGS: 00010046 RAX: RBX: RCX: 88803980 RDX: 0078 RSI: 88803980 RDI: 0800 RBP: 837ef3a0 R08: 0040 R09: 002e R10: 8132b7ea R11: 003f R12: 00035b40 R13: 888039800088 R14: c90002e6fc08 R15: 0200 FS: () GS:8880b9d0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0008 CR3: 11841000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __call_rcu kernel/rcu/tree.c:2965 [inline] call_rcu+0xbb/0x710 kernel/rcu/tree.c:3038 ipc_rcu_putref+0x83/0xb0 ipc/util.c:505 freeary+0x139c/0x1b30 ipc/sem.c:1188 free_ipcs+0x98/0x1e0 ipc/namespace.c:112 sem_exit_ns+0x1b/0x40 ipc/sem.c:260 free_ipc_ns ipc/namespace.c:124 [inline] free_ipc+0xf8/0x200 ipc/namespace.c:141 process_one_work+0x98d/0x1630 kernel/workqueue.c:2275 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 kthread+0x3b1/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Modules linked in: CR2: 0008 ---[ end trace 28dc093e61d44dc2 ]--- RIP: 0010:kasan_record_aux_stack+0x77/0xb0 mm/kasan/generic.c:341 Code: 48 f7 fe 8b 47 24 49 89 f0 48 29 d3 8d 70 ff 41 0f af f0 48 01 ce 48 39 f3 48 0f 46 f3 e8 81 e9 ff ff bf 00 08 00 00 48 89 c3 <8b> 40 08 89 43 0c e8 1e e6 ff ff 89 43 08 5b c3 48 8b 50 08 48 c7 RSP: 0018:c90002e6fae8 EFLAGS: 00010046 RAX: RBX: RCX: 88803980 RDX: 0078 RSI: 88803980 RDI: 0800 RBP: 837ef3a0 R08: 0040 R09: 002e R10: 8132b7ea R11: 003f R12: 00035b40 R13: 888039800088 R14: c90002e6fc08 R15: 0200 FS: () GS:8880b9d0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0008 CR3: 11841000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: BUG: unable to handle kernel NULL pointer dereference in __lookup_slow
syzbot has found a reproducer for the following issue on: HEAD commit:a68a0262 mm/madvise: remove racy mm ownership check git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15b3609750 kernel config: https://syzkaller.appspot.com/x/.config?x=e597c2b53c984cd8 dashboard link: https://syzkaller.appspot.com/bug?extid=3db80bbf66b88d68af9d compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project.git ca2dcbd030eadbf0aa9b660efe864ff08af6e18b) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1737b8a750 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1697246b50 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+3db80bbf66b88d68a...@syzkaller.appspotmail.com REISERFS (device loop0): journal params: device loop0, size 8192, journal first block 18, max trans len 256, max batch 225, max commit age 30, max trans age 30 REISERFS (device loop0): checking transaction log (loop0) REISERFS (device loop0): Using rupasov hash to sort names REISERFS (device loop0): using 3.5.x disk format BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 1d5b1067 P4D 1d5b1067 PUD 13a4d067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 8464 Comm: syz-executor889 Not tainted 5.10.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c900015ffa10 EFLAGS: 00010246 RAX: 113857c8 RBX: dc00 RCX: 8880152c8000 RDX: RSI: 88802e27dbe8 RDI: 888034c90190 RBP: 89c2be40 R08: 81c397ee R09: fbfff1eabc57 R10: fbfff1eabc57 R11: R12: R13: 888034c90190 R14: 111005c4fb7d R15: 88802e27dbe8 FS: 023f0880() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 12d42000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __lookup_slow+0x240/0x370 fs/namei.c:1544 lookup_one_len+0x10e/0x200 fs/namei.c:2563 reiserfs_lookup_privroot+0x85/0x1e0 fs/reiserfs/xattr.c:979 reiserfs_fill_super+0x2a57/0x3140 fs/reiserfs/super.c:2176 mount_bdev+0x24f/0x360 fs/super.c:1419 legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x88/0x270 fs/super.c:1549 do_new_mount fs/namespace.c:2875 [inline] path_mount+0x17b4/0x2a20 fs/namespace.c:3205 do_mount fs/namespace.c:3218 [inline] __do_sys_mount fs/namespace.c:3426 [inline] __se_sys_mount+0x28c/0x320 fs/namespace.c:3403 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x44707a Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 da ad fb ff c3 66 0f 1f 84 00 00 00 00 00 RSP: 002b:7ffc217e9828 EFLAGS: 0297 ORIG_RAX: 00a5 RAX: ffda RBX: 7ffc217e9880 RCX: 0044707a RDX: 2000 RSI: 2100 RDI: 7ffc217e9840 RBP: 7ffc217e9840 R08: 7ffc217e9880 R09: 7ffc0015 R10: R11: 0297 R12: 0006 R13: 0004 R14: 0003 R15: 0003 Modules linked in: CR2: ---[ end trace f20ed6d33f177882 ]--- RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c900015ffa10 EFLAGS: 00010246 RAX: 113857c8 RBX: dc00 RCX: 8880152c8000 RDX: RSI: 88802e27dbe8 RDI: 888034c90190 RBP: 89c2be40 R08: 81c397ee R09: fbfff1eabc57 R10: fbfff1eabc57 R11: R12: R13: 888034c90190 R14: 111005c4fb7d R15: 88802e27dbe8 FS: 023f0880() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 12d42000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400
BUG: unable to handle kernel NULL pointer dereference in fbcon_cursor
Hello, syzbot found the following issue on: HEAD commit:6dd65e60 Add linux-next specific files for 20201110 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1276af6250 kernel config: https://syzkaller.appspot.com/x/.config?x=4fab43daf5c54712 dashboard link: https://syzkaller.appspot.com/bug?extid=b67aaae8d3a927f68d20 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+b67aaae8d3a927f68...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 4e683067 P4D 4e683067 PUD 14850067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 9433 Comm: syz-executor.5 Not tainted 5.10.0-rc3-next-20201110-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c9000bca7858 EFLAGS: 00010286 RAX: RBX: RCX: RDX: 0002 RSI: 888144509000 RDI: 888010079000 RBP: 888010079000 R08: R09: 8cecc387 R10: 0003 R11: R12: 888144509000 R13: R14: R15: 0720 FS: 7f5822bee700() GS:8880b9e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 4e973000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: fbcon_cursor+0x50e/0x620 drivers/video/fbdev/core/fbcon.c:1346 hide_cursor+0x85/0x280 drivers/tty/vt/vt.c:907 redraw_screen+0x5ed/0x790 drivers/tty/vt/vt.c:1012 vc_do_resize+0xed3/0x1150 drivers/tty/vt/vt.c:1326 fbcon_set_disp+0x831/0xda0 drivers/video/fbdev/core/fbcon.c:1413 con2fb_init_display drivers/video/fbdev/core/fbcon.c:816 [inline] set_con2fb_map+0x7a6/0xf80 drivers/video/fbdev/core/fbcon.c:887 fbcon_set_con2fb_map_ioctl+0x165/0x220 drivers/video/fbdev/core/fbcon.c:3072 do_fb_ioctl+0x5b6/0x690 drivers/video/fbdev/core/fbmem.c:1156 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1185 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45deb9 Code: 0d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 db b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f5822bedc78 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: e2c0 RCX: 0045deb9 RDX: 20c0 RSI: 4610 RDI: 0006 RBP: 0118bf60 R08: R09: R10: R11: 0246 R12: 0118bf2c R13: 7ffe024fb66f R14: 7f5822bee9c0 R15: 0118bf2c Modules linked in: CR2: BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 4e683067 P4D 4e683067 PUD 14850067 PMD 0 Oops: 0010 [#2] PREEMPT SMP KASAN CPU: 0 PID: 9433 Comm: syz-executor.5 Not tainted 5.10.0-rc3-next-20201110-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c9000bca7278 EFLAGS: 00010086 RAX: 0007 RBX: RCX: 0007 RDX: 0002 RSI: 888144509000 RDI: 888010079000 RBP: 888010079000 R08: R09: 8cecc387 R10: 0003 R11: 0001 R12: 888144509000 R13: R14: R15: 0720 FS: 7f5822bee700() GS:8880b9e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 4e973000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: fbcon_cursor+0x50e/0x620 drivers/video/fbdev/core/fbcon.c:1346 hide_cursor+0x85/0x280 drivers/tty/vt/vt.c:907 redraw_screen+0x5ed/0x790 drivers/tty/vt/vt.c:1012 fbcon_blank+0x8c5/0xc30 drivers/video/fbdev/core/fbcon.c:2248 do_unblank_screen+0x25b/0x470 drivers/tty/vt/vt.c:4406 bust_spinlocks+0x5b/0xe0 lib/bust_spinlocks.c:26 oops_end+0x2b/0xe0 arch/x86/kernel/dumpstack.c:346 no_context+0x5f2/0xa20 arch/x86/mm/fault.c:752 __bad_
Re: linux-next boot error: BUG: unable to handle kernel NULL pointer dereference in mempool_init_node
On Wed, Nov 11, 2020 at 8:27 PM Lorenzo Stoakes wrote: > > On Wed, 11 Nov 2020 at 17:44, Andrey Konovalov wrote: > > I'll try to reproduce this and figure out the issue. Thanks for letting us > > know! > > I hope you don't mind me diving in here, I was taking a look just now > and managed to reproduce this locally - I bisected the issue to > 105397399 ("kasan: simplify kasan_poison_kfree"). > > If I stick a simple check in as below it fixes the issue, so I'm > guessing something is violating the assumptions in 105397399? > > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c > index 7a94cebc0324..16163159a017 100644 > --- a/mm/kasan/common.c > +++ b/mm/kasan/common.c > @@ -387,6 +387,11 @@ void __kasan_slab_free_mempool(void *ptr, unsigned long > ip) > struct page *page; > > page = virt_to_head_page(ptr); > + > + if (!PageSlab(page)) { > + return; > + } > + > kasan_slab_free(page->slab_cache, ptr, ip, false); > } Ah, by the looks of it, ceph's init_caches() functions asks for kmalloc-backed mempool, but at the same time provides a size that doesn't fit into any kmalloc cache, and kmalloc falls back onto page_alloc. Hard to say whether this is an issue in ceph, but I guess we'll have to make KASAN fool proof either way and keep the PageSlab() check in kasan_slab_free_mempool(). Thank you for debugging this, Lorenzo. I'll fix this in v10.
Re: linux-next boot error: BUG: unable to handle kernel NULL pointer dereference in mempool_init_node
On Wed, 11 Nov 2020 at 17:44, Andrey Konovalov wrote: > I'll try to reproduce this and figure out the issue. Thanks for letting us > know! I hope you don't mind me diving in here, I was taking a look just now and managed to reproduce this locally - I bisected the issue to 105397399 ("kasan: simplify kasan_poison_kfree"). If I stick a simple check in as below it fixes the issue, so I'm guessing something is violating the assumptions in 105397399? diff --git a/mm/kasan/common.c b/mm/kasan/common.c index 7a94cebc0324..16163159a017 100644 --- a/mm/kasan/common.c +++ b/mm/kasan/common.c @@ -387,6 +387,11 @@ void __kasan_slab_free_mempool(void *ptr, unsigned long ip) struct page *page; page = virt_to_head_page(ptr); + + if (!PageSlab(page)) { + return; + } + kasan_slab_free(page->slab_cache, ptr, ip, false); } -- Lorenzo Stoakes https://ljs.io
Re: linux-next boot error: BUG: unable to handle kernel NULL pointer dereference in mempool_init_node
On Wed, Nov 11, 2020 at 5:26 PM Qian Cai wrote: > > It looks to me the code paths below had recently been modified heavily by this > patchset. If this is reproducible, it can be confirmed by reverting it. > > https://lore.kernel.org/linux-arm-kernel/cover.1605046662.git.andreyk...@google.com/ I'll try to reproduce this and figure out the issue. Thanks for letting us know!
Re: linux-next boot error: BUG: unable to handle kernel NULL pointer dereference in mempool_init_node
It looks to me the code paths below had recently been modified heavily by this patchset. If this is reproducible, it can be confirmed by reverting it. https://lore.kernel.org/linux-arm-kernel/cover.1605046662.git.andreyk...@google.com/ On Tue, 2020-11-10 at 23:45 -0800, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:3e14f70c Add linux-next specific files for 2020 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=12e6af6250 > kernel config: https://syzkaller.appspot.com/x/.config?x=d6f4c7e100b61b76 > dashboard link: https://syzkaller.appspot.com/bug?extid=2d6f3dad1a42d86a5801 > compiler: gcc (GCC) 10.1.0-syz 20200507 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+2d6f3dad1a42d86a5...@syzkaller.appspotmail.com > > RPC: Registered named UNIX socket transport module. > RPC: Registered udp transport module. > RPC: Registered tcp transport module. > RPC: Registered tcp NFSv4.1 backchannel transport module. > NET: Registered protocol family 44 > pci_bus :00: resource 4 [io 0x-0x0cf7 window] > pci_bus :00: resource 5 [io 0x0d00-0x window] > pci_bus :00: resource 6 [mem 0x000a-0x000b window] > pci_bus :00: resource 7 [mem 0xc000-0xfebfefff window] > pci :00:00.0: Limiting direct PCI/PCI transfers > PCI: CLS 0 bytes, default 64 > PCI-DMA: Using software bounce buffering for IO (SWIOTLB) > software IO TLB: mapped [mem 0xb5e0-0xb9e0] (64MB) > RAPL PMU: API unit is 2^-32 Joules, 0 fixed counters, 10737418240 ms ovfl > timer > kvm: already loaded the other module > clocksource: tsc: mask: 0x max_cycles: 0x212735223b2, > max_idle_ns: 440795277976 ns > clocksource: Switched to clocksource tsc > Initialise system trusted keyrings > workingset: timestamp_bits=40 max_order=21 bucket_order=0 > zbud: loaded > DLM installed > squashfs: version 4.0 (2009/01/31) Phillip Lougher > FS-Cache: Netfs 'nfs' registered for caching > NFS: Registering the id_resolver key type > Key type id_resolver registered > Key type id_legacy registered > nfs4filelayout_init: NFSv4 File Layout Driver Registering... > Installing knfsd (copyright (C) 1996 o...@monad.swb.de). > FS-Cache: Netfs 'cifs' registered for caching > Key type cifs.spnego registered > Key type cifs.idmap registered > ntfs: driver 2.1.32 [Flags: R/W]. > efs: 1.0a - http://aeschi.ch.eu.org/efs/ > jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. > romfs: ROMFS MTD (C) 2007 Red Hat, Inc. > QNX4 filesystem 0.2.3 registered. > qnx6: QNX6 filesystem 1.0.0 registered. > fuse: init (API version 7.32) > orangefs_debugfs_init: called with debug mask: :none: :0: > orangefs_init: module version upstream loaded > JFS: nTxBlock = 8192, nTxLock = 65536 > SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled > 9p: Installing v9fs 9p2000 file system support > FS-Cache: Netfs '9p' registered for caching > NILFS version 2 loaded > befs: version: 0.9.3 > ocfs2: Registered cluster interface o2cb > ocfs2: Registered cluster interface user > OCFS2 User DLM kernel interface loaded > gfs2: GFS2 installed > BUG: kernel NULL pointer dereference, address: 0018 > #PF: supervisor read access in kernel mode > #PF: error_code(0x) - not-present page > PGD 0 P4D 0 > Oops: [#1] PREEMPT SMP KASAN > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0-rc3-next-2020-syzkaller > #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google > 01/01/2011 > RIP: 0010:nearest_obj include/linux/slub_def.h:169 [inline] > RIP: 0010:kasan_slab_free+0x19/0x110 mm/kasan/common.c:350 > Code: 00 48 c7 c0 fb ff ff ff c3 cc cc cc cc cc cc cc cc 41 55 49 89 d5 41 54 > 49 89 fc 48 89 f7 55 48 89 f5 53 89 cb e8 f7 27 7e ff <41> 8b 7c 24 18 48 be > 00 00 00 00 00 16 00 00 48 c1 e8 0c 48 89 c1 > RSP: :c9c67d30 EFLAGS: 00010293 > RAX: 0001436d RBX: RCX: 8130a760 > RDX: 888140748000 RSI: 8130a76a RDI: 0007 > RBP: 8881436d R08: 00fe R09: ed10286da800 > R10: R11: R12: > R13: 81945766 R14: 888143557944 R15: 81943b80 > FS: () GS:8880b9e0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 0018 CR3: 0b08e000 CR4: 001506f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > kasan_slab_free_mempool include/linux/kasan.h:202 [inline] > kasan_poison_element mm/mempool.c:107 [inline] > add_element mm/mempool.c:124 [inline] > mempool_init_node+0x37e/0x580 mm/mempool.c:205 > mempool_create_node mm/mempool.c:269 [inline] > mempool_create+0x76/0xc0 mm/mempool.c:254 > mempool_create_kma
linux-next boot error: BUG: unable to handle kernel NULL pointer dereference in mempool_init_node
Hello, syzbot found the following issue on: HEAD commit:3e14f70c Add linux-next specific files for 2020 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=12e6af6250 kernel config: https://syzkaller.appspot.com/x/.config?x=d6f4c7e100b61b76 dashboard link: https://syzkaller.appspot.com/bug?extid=2d6f3dad1a42d86a5801 compiler: gcc (GCC) 10.1.0-syz 20200507 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+2d6f3dad1a42d86a5...@syzkaller.appspotmail.com RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. NET: Registered protocol family 44 pci_bus :00: resource 4 [io 0x-0x0cf7 window] pci_bus :00: resource 5 [io 0x0d00-0x window] pci_bus :00: resource 6 [mem 0x000a-0x000b window] pci_bus :00: resource 7 [mem 0xc000-0xfebfefff window] pci :00:00.0: Limiting direct PCI/PCI transfers PCI: CLS 0 bytes, default 64 PCI-DMA: Using software bounce buffering for IO (SWIOTLB) software IO TLB: mapped [mem 0xb5e0-0xb9e0] (64MB) RAPL PMU: API unit is 2^-32 Joules, 0 fixed counters, 10737418240 ms ovfl timer kvm: already loaded the other module clocksource: tsc: mask: 0x max_cycles: 0x212735223b2, max_idle_ns: 440795277976 ns clocksource: Switched to clocksource tsc Initialise system trusted keyrings workingset: timestamp_bits=40 max_order=21 bucket_order=0 zbud: loaded DLM installed squashfs: version 4.0 (2009/01/31) Phillip Lougher FS-Cache: Netfs 'nfs' registered for caching NFS: Registering the id_resolver key type Key type id_resolver registered Key type id_legacy registered nfs4filelayout_init: NFSv4 File Layout Driver Registering... Installing knfsd (copyright (C) 1996 o...@monad.swb.de). FS-Cache: Netfs 'cifs' registered for caching Key type cifs.spnego registered Key type cifs.idmap registered ntfs: driver 2.1.32 [Flags: R/W]. efs: 1.0a - http://aeschi.ch.eu.org/efs/ jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. romfs: ROMFS MTD (C) 2007 Red Hat, Inc. QNX4 filesystem 0.2.3 registered. qnx6: QNX6 filesystem 1.0.0 registered. fuse: init (API version 7.32) orangefs_debugfs_init: called with debug mask: :none: :0: orangefs_init: module version upstream loaded JFS: nTxBlock = 8192, nTxLock = 65536 SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled 9p: Installing v9fs 9p2000 file system support FS-Cache: Netfs '9p' registered for caching NILFS version 2 loaded befs: version: 0.9.3 ocfs2: Registered cluster interface o2cb ocfs2: Registered cluster interface user OCFS2 User DLM kernel interface loaded gfs2: GFS2 installed BUG: kernel NULL pointer dereference, address: 0018 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 0 P4D 0 Oops: [#1] PREEMPT SMP KASAN CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0-rc3-next-2020-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:nearest_obj include/linux/slub_def.h:169 [inline] RIP: 0010:kasan_slab_free+0x19/0x110 mm/kasan/common.c:350 Code: 00 48 c7 c0 fb ff ff ff c3 cc cc cc cc cc cc cc cc 41 55 49 89 d5 41 54 49 89 fc 48 89 f7 55 48 89 f5 53 89 cb e8 f7 27 7e ff <41> 8b 7c 24 18 48 be 00 00 00 00 00 16 00 00 48 c1 e8 0c 48 89 c1 RSP: :c9c67d30 EFLAGS: 00010293 RAX: 0001436d RBX: RCX: 8130a760 RDX: 888140748000 RSI: 8130a76a RDI: 0007 RBP: 8881436d R08: 00fe R09: ed10286da800 R10: R11: R12: R13: 81945766 R14: 888143557944 R15: 81943b80 FS: () GS:8880b9e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0018 CR3: 0b08e000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: kasan_slab_free_mempool include/linux/kasan.h:202 [inline] kasan_poison_element mm/mempool.c:107 [inline] add_element mm/mempool.c:124 [inline] mempool_init_node+0x37e/0x580 mm/mempool.c:205 mempool_create_node mm/mempool.c:269 [inline] mempool_create+0x76/0xc0 mm/mempool.c:254 mempool_create_kmalloc_pool include/linux/mempool.h:88 [inline] init_caches fs/ceph/super.c:785 [inline] init_ceph+0x193/0x2d7 fs/ceph/super.c:1261 do_one_initcall+0x103/0x650 init/main.c:1212 do_initcall_level init/main.c:1285 [inline] do_initcalls init/main.c:1301 [inline] do_basic_setup init/main.c:1321 [inline] kernel_init_freeable+0x600/0x684 init/main.c:1521 kernel_init+0xd/0x1b8 init/main.c:1410 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Modules linked in: CR2: 00
BUG: unable to handle kernel NULL pointer dereference in __lookup_slow
Hello, syzbot found the following issue on: HEAD commit:7c7ec322 Merge tag 'for-linus' of git://git.kernel.org/pub.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1728977390 kernel config: https://syzkaller.appspot.com/x/.config?x=240e2ebab67245c7 dashboard link: https://syzkaller.appspot.com/bug?extid=3db80bbf66b88d68af9d compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+3db80bbf66b88d68a...@syzkaller.appspotmail.com REISERFS (device loop1): Using r5 hash to sort names REISERFS (device loop1): using 3.5.x disk format BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD a7454067 P4D a7454067 PUD 93380067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 9128 Comm: syz-executor.1 Not tainted 5.9.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:c90008bbf910 EFLAGS: 00010246 RAX: dc00 RBX: 192001177f25 RCX: c9000aad7000 RDX: RSI: 888085c9f330 RDI: 88804358f7e0 RBP: 889c4280 R08: 0001 R09: 8d461a7f R10: R11: 0005f088 R12: 888085c9f330 R13: 88804358f7e0 R14: c90008bbfaa0 R15: c90008bbf948 FS: 7f6bb6cc7700() GS:8880ae40() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: a75b9000 CR4: 001526f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __lookup_slow+0x24c/0x480 fs/namei.c:1544 lookup_one_len+0x163/0x190 fs/namei.c:2562 reiserfs_lookup_privroot+0x92/0x280 fs/reiserfs/xattr.c:972 reiserfs_fill_super+0x211b/0x2df3 fs/reiserfs/super.c:2176 mount_bdev+0x32e/0x3f0 fs/super.c:1417 legacy_get_tree+0x105/0x220 fs/fs_context.c:592 vfs_get_tree+0x89/0x2f0 fs/super.c:1547 do_new_mount fs/namespace.c:2875 [inline] path_mount+0x1387/0x20a0 fs/namespace.c:3192 do_mount fs/namespace.c:3205 [inline] __do_sys_mount fs/namespace.c:3413 [inline] __se_sys_mount fs/namespace.c:3390 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3390 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x460bca Code: b8 a6 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 dd 87 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 ba 87 fb ff c3 66 0f 1f 84 00 00 00 00 00 RSP: 002b:7f6bb6cc6a88 EFLAGS: 0202 ORIG_RAX: 00a5 RAX: ffda RBX: 7f6bb6cc6b20 RCX: 00460bca RDX: 2000 RSI: 2100 RDI: 7f6bb6cc6ae0 RBP: 7f6bb6cc6ae0 R08: 7f6bb6cc6b20 R09: 2000 R10: 00a04850 R11: 0202 R12: 2000 R13: 2100 R14: 2200 R15: 2040 Modules linked in: CR2: ---[ end trace 79d7e2c3db21cbd3 ]--- RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:c90008bbf910 EFLAGS: 00010246 RAX: dc00 RBX: 192001177f25 RCX: c9000aad7000 RDX: RSI: 888085c9f330 RDI: 88804358f7e0 RBP: 889c4280 R08: 0001 R09: 8d461a7f R10: R11: 0005f088 R12: 888085c9f330 R13: 88804358f7e0 R14: c90008bbfaa0 R15: c90008bbf948 FS: 7f6bb6cc7700() GS:8880ae50() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 558411c291f8 CR3: a75b9000 CR4: 001526e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: BUG: unable to handle kernel NULL pointer dereference in map_vdso
On Mon, Sep 21, 2020 at 12:35 PM Dmitry Vyukov wrote: > > On Mon, Sep 21, 2020 at 12:34 PM syzbot > wrote: > > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:92ab97ad Merge tag 'sh-for-5.9-part2' of git://git.libc.or.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=162d70d390 > > kernel config: https://syzkaller.appspot.com/x/.config?x=cd992d74d6c7e62 > > dashboard link: https://syzkaller.appspot.com/bug?extid=9d25c706da4558b9f11a > > compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ > > c2443155a0fb245c8f17f2c1c72b6ea391e86e81) > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+9d25c706da4558b9f...@syzkaller.appspotmail.com > > > > BUG: kernel NULL pointer dereference, address: > > #PF: supervisor write access in kernel mode > > #PF: error_code(0x0002) - not-present page > > PGD 0 P4D 0 > > Oops: 0002 [#1] PREEMPT SMP KASAN > > CPU: 0 PID: 5029 Comm: systemd-rfkill Not tainted 5.9.0-rc5-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > RIP: 0010:map_vdso+0x1ea/0x270 arch/x86/entry/vdso/vma.c:308 > > Code: 24 31 c9 e8 88 7c a7 00 eb 7a 4c 8b 74 24 28 43 80 3c 3e 00 48 8b 5c > > 24 08 74 08 4c 89 ef e8 4d 00 00 00 00 20 05 00 00 49 03 <6d> 00 48 89 e8 > > 48 c1 e8 03 42 80 3c 38 00 74 08 48 89 ef e8 ae 64 > > RSP: 0018:c90016bafb98 EFLAGS: 00010282 > > RAX: ab3c6738 RBX: 888056ebc538 RCX: 888093622440 > > RDX: RSI: RDI: > > RBP: 888056ebc480 R08: 81912471 R09: fbfff131e57c > > R10: fbfff131e57c R11: R12: 7fffda9dc000 > > R13: 888093622868 R14: 1110126c450d R15: dc00 > > FS: () GS:8880ae80() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: CR3: 8fac6000 CR4: 001526f0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > Call Trace: > > load_elf_binary+0x2e90/0x48a0 fs/binfmt_elf.c:1221 > > search_binary_handler fs/exec.c:1819 [inline] > > exec_binprm fs/exec.c:1860 [inline] > > bprm_execve+0x919/0x1500 fs/exec.c:1931 > > do_execveat_common+0x487/0x5f0 fs/exec.c:2026 > > do_execve fs/exec.c:2094 [inline] > > __do_sys_execve fs/exec.c:2170 [inline] > > __se_sys_execve fs/exec.c:2165 [inline] > > __x64_sys_execve+0x8e/0xa0 fs/exec.c:2165 > > do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > RIP: 0033:0x7f8127340647 > > Code: Bad RIP value. > > RSP: 002b:7ffc7b57dbf8 EFLAGS: 0246 ORIG_RAX: 003b > > RAX: ffda RBX: 55a0c9286d40 RCX: 7f8127340647 > > RDX: 55a0c9307440 RSI: 55a0c91cd210 RDI: 55a0c924e9a0 > > RBP: 7ffc7b57dd60 R08: fe00 R09: 0030 > > R10: 55a0c9239740 R11: 0246 R12: 55a0c91e1228 > > R13: R14: 55a0c91cd210 R15: 7ffc7b57de40 > > Modules linked in: > > CR2: > > > > > > --- > > This report is generated by a bot. It may contain errors. > > See https://goo.gl/tpsmEJ for more information about syzbot. > > syzbot engineers can be reached at syzkal...@googlegroups.com. > > > > syzbot will keep track of this issue. See: > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > Another clang-only crash that may be related to these ones: > > https://syzkaller.appspot.com/bug?extid=ce179bc99e64377c24bc > https://syzkaller.appspot.com/bug?extid=1dccfcb049726389379c There is strong indication that this is a manifestation of the same problem we see in other crashes. Let's make one canonical bug for this: #syz dup: general protection fault in perf_misc_flags
Re: BUG: unable to handle kernel NULL pointer dereference in map_vdso
On Mon, Sep 21, 2020 at 12:34 PM syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:92ab97ad Merge tag 'sh-for-5.9-part2' of git://git.libc.or.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=162d70d390 > kernel config: https://syzkaller.appspot.com/x/.config?x=cd992d74d6c7e62 > dashboard link: https://syzkaller.appspot.com/bug?extid=9d25c706da4558b9f11a > compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ > c2443155a0fb245c8f17f2c1c72b6ea391e86e81) > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+9d25c706da4558b9f...@syzkaller.appspotmail.com > > BUG: kernel NULL pointer dereference, address: > #PF: supervisor write access in kernel mode > #PF: error_code(0x0002) - not-present page > PGD 0 P4D 0 > Oops: 0002 [#1] PREEMPT SMP KASAN > CPU: 0 PID: 5029 Comm: systemd-rfkill Not tainted 5.9.0-rc5-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:map_vdso+0x1ea/0x270 arch/x86/entry/vdso/vma.c:308 > Code: 24 31 c9 e8 88 7c a7 00 eb 7a 4c 8b 74 24 28 43 80 3c 3e 00 48 8b 5c 24 > 08 74 08 4c 89 ef e8 4d 00 00 00 00 20 05 00 00 49 03 <6d> 00 48 89 e8 48 c1 > e8 03 42 80 3c 38 00 74 08 48 89 ef e8 ae 64 > RSP: 0018:c90016bafb98 EFLAGS: 00010282 > RAX: ab3c6738 RBX: 888056ebc538 RCX: 888093622440 > RDX: RSI: RDI: > RBP: 888056ebc480 R08: 81912471 R09: fbfff131e57c > R10: fbfff131e57c R11: R12: 7fffda9dc000 > R13: 888093622868 R14: 1110126c450d R15: dc00 > FS: () GS:8880ae80() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: CR3: 8fac6000 CR4: 001526f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > load_elf_binary+0x2e90/0x48a0 fs/binfmt_elf.c:1221 > search_binary_handler fs/exec.c:1819 [inline] > exec_binprm fs/exec.c:1860 [inline] > bprm_execve+0x919/0x1500 fs/exec.c:1931 > do_execveat_common+0x487/0x5f0 fs/exec.c:2026 > do_execve fs/exec.c:2094 [inline] > __do_sys_execve fs/exec.c:2170 [inline] > __se_sys_execve fs/exec.c:2165 [inline] > __x64_sys_execve+0x8e/0xa0 fs/exec.c:2165 > do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x7f8127340647 > Code: Bad RIP value. > RSP: 002b:7ffc7b57dbf8 EFLAGS: 0246 ORIG_RAX: 003b > RAX: ffda RBX: 55a0c9286d40 RCX: 7f8127340647 > RDX: 55a0c9307440 RSI: 55a0c91cd210 RDI: 55a0c924e9a0 > RBP: 7ffc7b57dd60 R08: fe00 R09: 0030 > R10: 55a0c9239740 R11: 0246 R12: 55a0c91e1228 > R13: R14: 55a0c91cd210 R15: 7ffc7b57de40 > Modules linked in: > CR2: > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. Another clang-only crash that may be related to these ones: https://syzkaller.appspot.com/bug?extid=ce179bc99e64377c24bc https://syzkaller.appspot.com/bug?extid=1dccfcb049726389379c
BUG: unable to handle kernel NULL pointer dereference in map_vdso
Hello, syzbot found the following issue on: HEAD commit:92ab97ad Merge tag 'sh-for-5.9-part2' of git://git.libc.or.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=162d70d390 kernel config: https://syzkaller.appspot.com/x/.config?x=cd992d74d6c7e62 dashboard link: https://syzkaller.appspot.com/bug?extid=9d25c706da4558b9f11a compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+9d25c706da4558b9f...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP KASAN CPU: 0 PID: 5029 Comm: systemd-rfkill Not tainted 5.9.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:map_vdso+0x1ea/0x270 arch/x86/entry/vdso/vma.c:308 Code: 24 31 c9 e8 88 7c a7 00 eb 7a 4c 8b 74 24 28 43 80 3c 3e 00 48 8b 5c 24 08 74 08 4c 89 ef e8 4d 00 00 00 00 20 05 00 00 49 03 <6d> 00 48 89 e8 48 c1 e8 03 42 80 3c 38 00 74 08 48 89 ef e8 ae 64 RSP: 0018:c90016bafb98 EFLAGS: 00010282 RAX: ab3c6738 RBX: 888056ebc538 RCX: 888093622440 RDX: RSI: RDI: RBP: 888056ebc480 R08: 81912471 R09: fbfff131e57c R10: fbfff131e57c R11: R12: 7fffda9dc000 R13: 888093622868 R14: 1110126c450d R15: dc00 FS: () GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 8fac6000 CR4: 001526f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: load_elf_binary+0x2e90/0x48a0 fs/binfmt_elf.c:1221 search_binary_handler fs/exec.c:1819 [inline] exec_binprm fs/exec.c:1860 [inline] bprm_execve+0x919/0x1500 fs/exec.c:1931 do_execveat_common+0x487/0x5f0 fs/exec.c:2026 do_execve fs/exec.c:2094 [inline] __do_sys_execve fs/exec.c:2170 [inline] __se_sys_execve fs/exec.c:2165 [inline] __x64_sys_execve+0x8e/0xa0 fs/exec.c:2165 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f8127340647 Code: Bad RIP value. RSP: 002b:7ffc7b57dbf8 EFLAGS: 0246 ORIG_RAX: 003b RAX: ffda RBX: 55a0c9286d40 RCX: 7f8127340647 RDX: 55a0c9307440 RSI: 55a0c91cd210 RDI: 55a0c924e9a0 RBP: 7ffc7b57dd60 R08: fe00 R09: 0030 R10: 55a0c9239740 R11: 0246 R12: 55a0c91e1228 R13: R14: 55a0c91cd210 R15: 7ffc7b57de40 Modules linked in: CR2: --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
BUG: unable to handle kernel NULL pointer dereference in qlist_free_all (8)
Hello, syzbot found the following issue on: HEAD commit:34d4ddd3 Merge tag 'linux-kselftest-5.9-rc5' of git://git... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=147c760d90 kernel config: https://syzkaller.appspot.com/x/.config?x=a9075b36a6ae26c9 dashboard link: https://syzkaller.appspot.com/bug?extid=4bba137eaf7cc94b57ca compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+4bba137eaf7cc94b5...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: 0080 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 4bbac067 P4D 4bbac067 PUD 9468a067 PMD 0 Oops: [#1] PREEMPT SMP KASAN CPU: 0 PID: 3936 Comm: syz-executor.0 Not tainted 5.9.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:qlink_to_object mm/kasan/quarantine.c:137 [inline] RIP: 0010:qlink_free mm/kasan/quarantine.c:142 [inline] RIP: 0010:qlist_free_all+0x36/0x170 mm/kasan/quarantine.c:168 Code: 53 48 83 ec 10 48 8b 37 48 85 f6 0f 84 36 01 00 00 49 bf 00 00 00 00 00 fc ff df 48 85 ed 49 89 fd 48 89 ef 0f 84 97 00 00 00 <48> 63 87 80 00 00 00 4c 8b 26 48 29 c6 48 83 3d 75 e5 01 08 00 0f RSP: 0018:c90004dd7a10 EFLAGS: 00010246 RAX: ea00 RBX: 0282 RCX: ea07 RDX: RSI: 8880 RDI: RBP: R08: 0001 R09: 8c5f5a77 R10: R11: 0001 R12: 8880 R13: c90004dd7a58 R14: 0200 R15: dc00 FS: 03563940() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0080 CR3: 3d19c000 CR4: 001526f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: quarantine_reduce+0x17e/0x200 mm/kasan/quarantine.c:261 __kasan_kmalloc.constprop.0+0x9e/0xd0 mm/kasan/common.c:442 slab_post_alloc_hook mm/slab.h:518 [inline] slab_alloc mm/slab.c:3312 [inline] __do_kmalloc mm/slab.c:3653 [inline] __kmalloc+0x178/0x310 mm/slab.c:3664 kmalloc include/linux/slab.h:559 [inline] kzalloc include/linux/slab.h:666 [inline] tomoyo_encode2.part.0+0xe9/0x3a0 security/tomoyo/realpath.c:45 tomoyo_encode2 security/tomoyo/realpath.c:31 [inline] tomoyo_encode+0x28/0x50 security/tomoyo/realpath.c:80 tomoyo_path_perm+0x35f/0x3f0 security/tomoyo/file.c:831 tomoyo_path_symlink+0x94/0xe0 security/tomoyo/tomoyo.c:200 security_path_symlink+0xdf/0x150 security/security.c:1109 do_symlinkat+0x123/0x2c0 fs/namei.c:3984 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45d2e7 Code: 0f 1f 00 b8 5c 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 1d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 58 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 fd b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:0169fda8 EFLAGS: 0202 ORIG_RAX: 0058 RAX: ffda RBX: RCX: 0045d2e7 RDX: 0169fe43 RSI: 004c30cd RDI: 0169fe30 RBP: R08: R09: 0013 R10: 0075 R11: 0202 R12: R13: 0169fde0 R14: R15: 0169fdf0 Modules linked in: CR2: 0080 ---[ end trace 9fd83eee6918f461 ]--- RIP: 0010:qlink_to_object mm/kasan/quarantine.c:137 [inline] RIP: 0010:qlink_free mm/kasan/quarantine.c:142 [inline] RIP: 0010:qlist_free_all+0x36/0x170 mm/kasan/quarantine.c:168 Code: 53 48 83 ec 10 48 8b 37 48 85 f6 0f 84 36 01 00 00 49 bf 00 00 00 00 00 fc ff df 48 85 ed 49 89 fd 48 89 ef 0f 84 97 00 00 00 <48> 63 87 80 00 00 00 4c 8b 26 48 29 c6 48 83 3d 75 e5 01 08 00 0f RSP: 0018:c90004dd7a10 EFLAGS: 00010246 RAX: ea00 RBX: 0282 RCX: ea07 RDX: RSI: 8880 RDI: RBP: R08: 0001 R09: 8c5f5a77 R10: R11: 0001 R12: 8880 R13: c90004dd7a58 R14: 0200 R15: dc00 FS: 03563940() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00749198 CR3: 3d19c000 CR4: 001526f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#sta
BUG: unable to handle kernel NULL pointer dereference in kvm_vm_worker_thread
Hello, syzbot found the following issue on: HEAD commit:15bc20c6 Merge tag 'tty-5.9-rc3' of git://git.kernel.org/p.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15d432fe90 kernel config: https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994 dashboard link: https://syzkaller.appspot.com/bug?extid=e4a6c438918d1db4e4fc compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e4a6c438918d1db4e...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 5d428067 P4D 5d428067 PUD 5d429067 PMD 0 Oops: 0002 [#1] PREEMPT SMP KASAN CPU: 0 PID: 7418 Comm: kvm-nx-lpage-re Not tainted 5.9.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:kvm_vm_worker_thread+0xe9/0x270 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4912 Code: 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 37 01 00 00 48 8b 7b 08 4c 89 ee e8 23 99 67 00 31 ff 41 89 c4 89 c6 e8 a7 4b 6d 00 <00> 00 00 0f 85 97 31 02 00 e8 19 4f 6d 00 48 8b 54 24 08 48 b8 00 RSP: 0018:c90012097ed0 EFLAGS: 00010293 RAX: RBX: c90011e87cf8 RCX: 8106efe9 RDX: RSI: 88804c02e040 RDI: 0005 RBP: c90011e87d08 R08: 0001 R09: 89bfd407 R10: R11: 0160 R12: R13: 88804c02e040 R14: c90012081000 R15: FS: () GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 5d427000 CR4: 001526f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: kthread+0x3b5/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Modules linked in: CR2: ---[ end trace 7a7affa1f4a7d557 ]--- RIP: 0010:kvm_vm_worker_thread+0xe9/0x270 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4912 Code: 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 37 01 00 00 48 8b 7b 08 4c 89 ee e8 23 99 67 00 31 ff 41 89 c4 89 c6 e8 a7 4b 6d 00 <00> 00 00 0f 85 97 31 02 00 e8 19 4f 6d 00 48 8b 54 24 08 48 b8 00 RSP: 0018:c90012097ed0 EFLAGS: 00010293 RAX: RBX: c90011e87cf8 RCX: 8106efe9 RDX: RSI: 88804c02e040 RDI: 0005 RBP: c90011e87d08 R08: 0001 R09: 89bfd407 R10: R11: 0160 R12: R13: 88804c02e040 R14: c90012081000 R15: FS: () GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 5d427000 CR4: 001526f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: BUG: unable to handle kernel NULL pointer dereference in loop_rw_iter
On 8/10/20 9:46 AM, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:9420f1ce Merge tag 'pinctrl-v5.9-1' of git://git.kernel.or.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=13662f6290 > kernel config: https://syzkaller.appspot.com/x/.config?x=72cf85e4237850c8 > dashboard link: https://syzkaller.appspot.com/bug?extid=1abbd16e49910f6bbe45 > compiler: gcc (GCC) 10.1.0-syz 20200507 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1592900690 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15e196aa90 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+1abbd16e49910f6bb...@syzkaller.appspotmail.com Already fixed, just not upstream yet: https://git.kernel.dk/cgit/linux-block/commit/?h=io_uring-5.9&id=2dd2111d0d383df104b144e0d1f6b5a00cb7cd88 -- Jens Axboe
BUG: unable to handle kernel NULL pointer dereference in loop_rw_iter
Hello, syzbot found the following issue on: HEAD commit:9420f1ce Merge tag 'pinctrl-v5.9-1' of git://git.kernel.or.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=13662f6290 kernel config: https://syzkaller.appspot.com/x/.config?x=72cf85e4237850c8 dashboard link: https://syzkaller.appspot.com/bug?extid=1abbd16e49910f6bbe45 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1592900690 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15e196aa90 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+1abbd16e49910f6bb...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD a652e067 P4D a652e067 PUD a652f067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 1 PID: 7461 Comm: io_wqe_worker-0 Not tainted 5.8.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:c9000804f910 EFLAGS: 00010246 RAX: 110b0b9b RBX: dc00 RCX: 88808962e1c8 RDX: 003c RSI: 2740 RDI: 88809fb2dcc0 RBP: 2740 R08: c9000804fa28 R09: 8880a7639c0f R10: R11: R12: c9000804fa28 R13: 88585cc0 R14: 003c R15: 0001 FS: () GS:8880ae70() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 8e2a7000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: loop_rw_iter.part.0+0x26e/0x450 fs/io_uring.c:2850 loop_rw_iter fs/io_uring.c:2829 [inline] io_write+0x6a2/0x7a0 fs/io_uring.c:3190 io_issue_sqe+0x1b0/0x60d0 fs/io_uring.c:5530 io_wq_submit_work+0x183/0x3d0 fs/io_uring.c:5775 io_worker_handle_work+0xa45/0x13f0 fs/io-wq.c:527 io_wqe_worker+0xbf0/0x10e0 fs/io-wq.c:569 kthread+0x3b5/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Modules linked in: CR2: ---[ end trace 97e511c5a98da2fe ]--- RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:c9000804f910 EFLAGS: 00010246 RAX: 110b0b9b RBX: dc00 RCX: 88808962e1c8 RDX: 003c RSI: 2740 RDI: 88809fb2dcc0 RBP: 2740 R08: c9000804fa28 R09: 8880a7639c0f R10: R11: R12: c9000804fa28 R13: 88585cc0 R14: 003c R15: 0001 FS: () GS:8880ae70() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f84c3b15028 CR3: 8e2a7000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: BUG: unable to handle kernel NULL pointer dereference in bpf_prog_ADDR
Eric Dumazet wrote: > > > On 8/2/20 3:45 PM, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:ac3a0c84 Merge git://git.kernel.org/pub/scm/linux/kernel/g.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=1323497090 > > kernel config: https://syzkaller.appspot.com/x/.config?x=c0cfcf935bcc94d2 > > dashboard link: https://syzkaller.appspot.com/bug?extid=192a7fbbece55f740074 > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=141541ea90 > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+192a7fbbece55f740...@syzkaller.appspotmail.com > > > > BUG: kernel NULL pointer dereference, address: > > #PF: supervisor read access in kernel mode > > #PF: error_code(0x) - not-present page > > PGD 9176a067 P4D 9176a067 PUD 9176b067 PMD 0 > > Oops: [#1] PREEMPT SMP KASAN > > CPU: 1 PID: 8142 Comm: syz-executor.2 Not tainted 5.8.0-rc7-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > RIP: 0010:bpf_prog_e48ebe87b99394c4+0x1f/0x590 > > Code: cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 55 48 89 e5 48 81 ec > > 00 00 00 00 53 41 55 41 56 41 57 6a 00 31 c0 48 8b 47 28 <48> 8b 40 00 8b > > 80 00 01 00 00 5b 41 5f 41 5e 41 5d 5b c9 c3 cc cc > > RSP: 0018:c900038a7b00 EFLAGS: 00010246 > > RAX: RBX: dc00 RCX: dc00 > > RDX: 88808cfb0200 RSI: c9e7e038 RDI: c900038a7ca8 > > RBP: c900038a7b28 R08: R09: > > R10: R11: R12: c9e7e000 > > R13: c9e7e000 R14: 0001 R15: > > FS: 7fda07fef700() GS:8880ae70() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: CR3: 91769000 CR4: 001406e0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > Call Trace: > > bpf_prog_run_xdp include/linux/filter.h:734 [inline] > > bpf_test_run+0x221/0xc70 net/bpf/test_run.c:47 > > bpf_prog_test_run_xdp+0x2ca/0x510 net/bpf/test_run.c:524 > > bpf_prog_test_run kernel/bpf/syscall.c:2983 [inline] > > __do_sys_bpf+0x2117/0x4b10 kernel/bpf/syscall.c:4135 > > do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > RIP: 0033:0x45cc79 > > Code: 2d b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 fb b5 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > > RSP: 002b:7fda07feec78 EFLAGS: 0246 ORIG_RAX: 0141 > > RAX: ffda RBX: 1740 RCX: 0045cc79 > > RDX: 0028 RSI: 2080 RDI: 000a > > RBP: 0078bfe0 R08: R09: > > R10: R11: 0246 R12: 0078bfac > > R13: 7ffc3ef769bf R14: 7fda07fef9c0 R15: 0078bfac > > Modules linked in: > > CR2: > > ---[ end trace b2d24107e7fdae7d ]--- > > RIP: 0010:bpf_prog_e48ebe87b99394c4+0x1f/0x590 > > Code: cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 55 48 89 e5 48 81 ec > > 00 00 00 00 53 41 55 41 56 41 57 6a 00 31 c0 48 8b 47 28 <48> 8b 40 00 8b > > 80 00 01 00 00 5b 41 5f 41 5e 41 5d 5b c9 c3 cc cc > > RSP: 0018:c900038a7b00 EFLAGS: 00010246 > > RAX: RBX: dc00 RCX: dc00 > > RDX: 88808cfb0200 RSI: c9e7e038 RDI: c900038a7ca8 > > RBP: c900038a7b28 R08: R09: > > R10: R11: R12: c9e7e000 > > R13: c9e7e000 R14: 0001 R15: > > FS: 7fda07fef700() GS:8880ae70() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: CR3: 91769000 CR4: 001406e0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > > > > > --- > > This report is generated by a bot. It may contain errors. > > See https://goo.gl/tpsmEJ for more information about syzbot. > > syzbot engineers can be reached at syzkal...@googlegroups.com. > > > > syzbot will keep track of this issue. See: > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > syzbot can test patches for this issue, for details see: > > https://goo.gl/tpsmEJ#testing-patches > > > > > # > https://syzkaller.appspot.com/bug?id=d60883a0b19a778d2bcab55f3f6459467f4a3ea7 > # See https://goo.gl/kgGztJ for information about syzkaller reproducers. > #{"threaded":true,"collide":
Re: BUG: unable to handle kernel NULL pointer dereference in bpf_prog_ADDR
On 8/2/20 3:45 PM, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:ac3a0c84 Merge git://git.kernel.org/pub/scm/linux/kernel/g.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1323497090 > kernel config: https://syzkaller.appspot.com/x/.config?x=c0cfcf935bcc94d2 > dashboard link: https://syzkaller.appspot.com/bug?extid=192a7fbbece55f740074 > compiler: gcc (GCC) 10.1.0-syz 20200507 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=141541ea90 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+192a7fbbece55f740...@syzkaller.appspotmail.com > > BUG: kernel NULL pointer dereference, address: > #PF: supervisor read access in kernel mode > #PF: error_code(0x) - not-present page > PGD 9176a067 P4D 9176a067 PUD 9176b067 PMD 0 > Oops: [#1] PREEMPT SMP KASAN > CPU: 1 PID: 8142 Comm: syz-executor.2 Not tainted 5.8.0-rc7-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:bpf_prog_e48ebe87b99394c4+0x1f/0x590 > Code: cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 55 48 89 e5 48 81 ec 00 > 00 00 00 53 41 55 41 56 41 57 6a 00 31 c0 48 8b 47 28 <48> 8b 40 00 8b 80 00 > 01 00 00 5b 41 5f 41 5e 41 5d 5b c9 c3 cc cc > RSP: 0018:c900038a7b00 EFLAGS: 00010246 > RAX: RBX: dc00 RCX: dc00 > RDX: 88808cfb0200 RSI: c9e7e038 RDI: c900038a7ca8 > RBP: c900038a7b28 R08: R09: > R10: R11: R12: c9e7e000 > R13: c9e7e000 R14: 0001 R15: > FS: 7fda07fef700() GS:8880ae70() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: CR3: 91769000 CR4: 001406e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > bpf_prog_run_xdp include/linux/filter.h:734 [inline] > bpf_test_run+0x221/0xc70 net/bpf/test_run.c:47 > bpf_prog_test_run_xdp+0x2ca/0x510 net/bpf/test_run.c:524 > bpf_prog_test_run kernel/bpf/syscall.c:2983 [inline] > __do_sys_bpf+0x2117/0x4b10 kernel/bpf/syscall.c:4135 > do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x45cc79 > Code: 2d b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 fb b5 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7fda07feec78 EFLAGS: 0246 ORIG_RAX: 0141 > RAX: ffda RBX: 1740 RCX: 0045cc79 > RDX: 0028 RSI: 2080 RDI: 000a > RBP: 0078bfe0 R08: R09: > R10: R11: 0246 R12: 0078bfac > R13: 7ffc3ef769bf R14: 7fda07fef9c0 R15: 0078bfac > Modules linked in: > CR2: > ---[ end trace b2d24107e7fdae7d ]--- > RIP: 0010:bpf_prog_e48ebe87b99394c4+0x1f/0x590 > Code: cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 55 48 89 e5 48 81 ec 00 > 00 00 00 53 41 55 41 56 41 57 6a 00 31 c0 48 8b 47 28 <48> 8b 40 00 8b 80 00 > 01 00 00 5b 41 5f 41 5e 41 5d 5b c9 c3 cc cc > RSP: 0018:c900038a7b00 EFLAGS: 00010246 > RAX: RBX: dc00 RCX: dc00 > RDX: 88808cfb0200 RSI: c9e7e038 RDI: c900038a7ca8 > RBP: c900038a7b28 R08: R09: > R10: R11: R12: c9e7e000 > R13: c9e7e000 R14: 0001 R15: > FS: 7fda07fef700() GS:8880ae70() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: CR3: 91769000 CR4: 001406e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > syzbot can test patches for this issue, for details see: > https://goo.gl/tpsmEJ#testing-patches > # https://syzkaller.appspot.com/bug?id=d60883a0b19a778d2bcab55f3f6459467f4a3ea7 # See https://goo.gl/kgGztJ for information about syzkaller reproducers. #{"threaded":true,"collide":true,"repeat":true,"procs":6,"sandbox":"none","fault_call":-1,"tun":true,"netdev":true,"resetnet":true,"cgroups":true,"binfmt_misc":true,"close_fds":true,"vhci":true,"tmpdir":true,"segv":true} bpf$PROG_LOAD(0x5
BUG: unable to handle kernel NULL pointer dereference in bpf_prog_ADDR
Hello, syzbot found the following issue on: HEAD commit:ac3a0c84 Merge git://git.kernel.org/pub/scm/linux/kernel/g.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1323497090 kernel config: https://syzkaller.appspot.com/x/.config?x=c0cfcf935bcc94d2 dashboard link: https://syzkaller.appspot.com/bug?extid=192a7fbbece55f740074 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=141541ea90 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+192a7fbbece55f740...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 9176a067 P4D 9176a067 PUD 9176b067 PMD 0 Oops: [#1] PREEMPT SMP KASAN CPU: 1 PID: 8142 Comm: syz-executor.2 Not tainted 5.8.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:bpf_prog_e48ebe87b99394c4+0x1f/0x590 Code: cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 55 48 89 e5 48 81 ec 00 00 00 00 53 41 55 41 56 41 57 6a 00 31 c0 48 8b 47 28 <48> 8b 40 00 8b 80 00 01 00 00 5b 41 5f 41 5e 41 5d 5b c9 c3 cc cc RSP: 0018:c900038a7b00 EFLAGS: 00010246 RAX: RBX: dc00 RCX: dc00 RDX: 88808cfb0200 RSI: c9e7e038 RDI: c900038a7ca8 RBP: c900038a7b28 R08: R09: R10: R11: R12: c9e7e000 R13: c9e7e000 R14: 0001 R15: FS: 7fda07fef700() GS:8880ae70() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 91769000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: bpf_prog_run_xdp include/linux/filter.h:734 [inline] bpf_test_run+0x221/0xc70 net/bpf/test_run.c:47 bpf_prog_test_run_xdp+0x2ca/0x510 net/bpf/test_run.c:524 bpf_prog_test_run kernel/bpf/syscall.c:2983 [inline] __do_sys_bpf+0x2117/0x4b10 kernel/bpf/syscall.c:4135 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45cc79 Code: 2d b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 fb b5 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fda07feec78 EFLAGS: 0246 ORIG_RAX: 0141 RAX: ffda RBX: 1740 RCX: 0045cc79 RDX: 0028 RSI: 2080 RDI: 000a RBP: 0078bfe0 R08: R09: R10: R11: 0246 R12: 0078bfac R13: 7ffc3ef769bf R14: 7fda07fef9c0 R15: 0078bfac Modules linked in: CR2: ---[ end trace b2d24107e7fdae7d ]--- RIP: 0010:bpf_prog_e48ebe87b99394c4+0x1f/0x590 Code: cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 55 48 89 e5 48 81 ec 00 00 00 00 53 41 55 41 56 41 57 6a 00 31 c0 48 8b 47 28 <48> 8b 40 00 8b 80 00 01 00 00 5b 41 5f 41 5e 41 5d 5b c9 c3 cc cc RSP: 0018:c900038a7b00 EFLAGS: 00010246 RAX: RBX: dc00 RCX: dc00 RDX: 88808cfb0200 RSI: c9e7e038 RDI: c900038a7ca8 RBP: c900038a7b28 R08: R09: R10: R11: R12: c9e7e000 R13: c9e7e000 R14: 0001 R15: FS: 7fda07fef700() GS:8880ae70() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 91769000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: BUG: unable to handle kernel NULL pointer dereference in do_syscall_32_irqs_on
Hello, On Sun, 2020-07-26 at 01:03 -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:23ee3e4e Merge tag 'pci-v5.8-fixes-2' of > git://git.kernel... > git tree: upstream > console output: > https://syzkaller.appspot.com/x/log.txt?x=14a4c7d890 > kernel config: > https://syzkaller.appspot.com/x/.config?x=f87a5e4232fdb267 > dashboard link: > https://syzkaller.appspot.com/bug?extid=0e3a50ab9ac2fdf9ffc6 > compiler: gcc (GCC) 10.1.0-syz 20200507 > userspace arch: i386 > syz repro: > https://syzkaller.appspot.com/x/repro.syz?x=168fe3a090 > > IMPORTANT: if you fix the issue, please add the following tag to the > commit: > Reported-by: syzbot+0e3a50ab9ac2fdf9f...@syzkaller.appspotmail.com > > BUG: kernel NULL pointer dereference, address: > #PF: supervisor write access in kernel mode > #PF: error_code(0x0002) - not-present page > PGD 94d49067 P4D 94d49067 PUD a1c93067 PMD 0 > Oops: 0002 [#1] PREEMPT SMP KASAN > CPU: 0 PID: 6854 Comm: syz-executor.3 Not tainted 5.8.0-rc6-syzkaller > #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, > BIOS Google 01/01/2011 > RIP: 0010:do_syscall_32_irqs_on+0x3f/0x60 arch/x86/entry/common.c:428 > Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > RSP: 0018:c900017b7f28 EFLAGS: 00010296 > RAX: RBX: c900017b7f58 RCX: 1920002f6fd2 > RDX: 888098bb4240 RSI: 81c214b2 RDI: 0005 > RBP: c900017b7f58 R08: 0001 R09: 888098bb4b08 > R10: ff8c R11: R12: 0001 > R13: R14: R15: > FS: () GS:8880ae60(0063) > knlGS:0a292900 > CS: 0010 DS: 002b ES: 002b CR0: 80050033 > CR2: CR3: a1b88000 CR4: 001406f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > __do_fast_syscall_32 arch/x86/entry/common.c:475 [inline] > do_fast_syscall_32+0x7f/0x120 arch/x86/entry/common.c:503 > entry_SYSENTER_compat_after_hwframe+0x4d/0x5c > BUG: kernel NULL pointer dereference, address: > #PF: supervisor write access in kernel mode > #PF: error_code(0x0002) - not-present page > PGD 94d49067 P4D 94d49067 PUD a1c93067 PMD 0 > Oops: 0002 [#2] PREEMPT SMP KASAN > CPU: 0 PID: 6854 Comm: syz-executor.3 Not tainted 5.8.0-rc6-syzkaller > #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, > BIOS Google 01/01/2011 > RIP: 0010:in_gate_area_no_mm+0x0/0x6a > arch/x86/entry/vsyscall/vsyscall_64.c:343 > Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > RSP: 0018:c900017b7440 EFLAGS: 00010093 > RAX: RBX: c900017b74e0 RCX: 816a62f0 > RDX: 888098bb4240 RSI: 816a631b RDI: f7f83569 > RBP: f7f83569 R08: c900017b75f0 R09: 8c8d7109 > R10: f7f83569 R11: R12: c900017b75f0 > R13: 0001 R14: f7f83569 R15: c900017b7500 > FS: () GS:8880ae60(0063) > knlGS:0a292900 > CS: 0010 DS: 002b ES: 002b CR0: 80050033 > CR2: CR3: a1b88000 CR4: 001406f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > is_kernel include/linux/kallsyms.h:44 [inline] > is_ksym_addr include/linux/kallsyms.h:50 [inline] > kallsyms_lookup+0xc3/0x2e0 kernel/kallsyms.c:290 > __sprint_symbol+0x9c/0x1c0 kernel/kallsyms.c:363 > symbol_string+0x14c/0x370 lib/vsprintf.c:969 > pointer+0x185/0x970 lib/vsprintf.c:2226 > vsnprintf+0x5b2/0x14f0 lib/vsprintf.c:2624 > vscnprintf+0x29/0x80 lib/vsprintf.c:2723 > vprintk_store+0x44/0x4a0 kernel/printk/printk.c:1942 > vprintk_emit+0x139/0x770 kernel/printk/printk.c:2003 > vprintk_func+0x8f/0x1a6 kernel/printk/printk_safe.c:393 > printk+0xba/0xed kernel/printk/printk.c:2070 > show_ip+0x22/0x30 arch/x86/kernel/dumpstack.c:124 > show_iret_regs+0x10/0x32 arch/x86/kernel/dumpstack.c:131 > __show_regs+0x18/0x50 arch/x86/kernel/process_64.c:72 > show_trace_log_lvl+0x255/0x2b4 arch/x86/kernel/dumpstack.c:274 > show_regs arch/x86/kernel/dumpstack.c:447 [inline] > __die_body arch/x86/kernel/dumpstack.c:393 [inline] > __die+0x51/0x90 arch/x86/kernel/dumpstack.c:407 > no_context+0x56b/0x9f0 arch/x86/mm/fault.c:695 > __bad_area_nosemaphore+0xa9/0x480 arch/x86/mm/fault.c:789 > do_user_addr_fault+0x8ce/0xd00 arch/x86/mm/fault.c:1258 > handle_page_fault
BUG: unable to handle kernel NULL pointer dereference in do_syscall_32_irqs_on
Hello, syzbot found the following issue on: HEAD commit:23ee3e4e Merge tag 'pci-v5.8-fixes-2' of git://git.kernel... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=14a4c7d890 kernel config: https://syzkaller.appspot.com/x/.config?x=f87a5e4232fdb267 dashboard link: https://syzkaller.appspot.com/bug?extid=0e3a50ab9ac2fdf9ffc6 compiler: gcc (GCC) 10.1.0-syz 20200507 userspace arch: i386 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=168fe3a090 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+0e3a50ab9ac2fdf9f...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 94d49067 P4D 94d49067 PUD a1c93067 PMD 0 Oops: 0002 [#1] PREEMPT SMP KASAN CPU: 0 PID: 6854 Comm: syz-executor.3 Not tainted 5.8.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:do_syscall_32_irqs_on+0x3f/0x60 arch/x86/entry/common.c:428 Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 RSP: 0018:c900017b7f28 EFLAGS: 00010296 RAX: RBX: c900017b7f58 RCX: 1920002f6fd2 RDX: 888098bb4240 RSI: 81c214b2 RDI: 0005 RBP: c900017b7f58 R08: 0001 R09: 888098bb4b08 R10: ff8c R11: R12: 0001 R13: R14: R15: FS: () GS:8880ae60(0063) knlGS:0a292900 CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: CR3: a1b88000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __do_fast_syscall_32 arch/x86/entry/common.c:475 [inline] do_fast_syscall_32+0x7f/0x120 arch/x86/entry/common.c:503 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c BUG: kernel NULL pointer dereference, address: #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 94d49067 P4D 94d49067 PUD a1c93067 PMD 0 Oops: 0002 [#2] PREEMPT SMP KASAN CPU: 0 PID: 6854 Comm: syz-executor.3 Not tainted 5.8.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:in_gate_area_no_mm+0x0/0x6a arch/x86/entry/vsyscall/vsyscall_64.c:343 Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 RSP: 0018:c900017b7440 EFLAGS: 00010093 RAX: RBX: c900017b74e0 RCX: 816a62f0 RDX: 888098bb4240 RSI: 816a631b RDI: f7f83569 RBP: f7f83569 R08: c900017b75f0 R09: 8c8d7109 R10: f7f83569 R11: R12: c900017b75f0 R13: 0001 R14: f7f83569 R15: c900017b7500 FS: () GS:8880ae60(0063) knlGS:0a292900 CS: 0010 DS: 002b ES: 002b CR0: 80050033 CR2: CR3: a1b88000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: is_kernel include/linux/kallsyms.h:44 [inline] is_ksym_addr include/linux/kallsyms.h:50 [inline] kallsyms_lookup+0xc3/0x2e0 kernel/kallsyms.c:290 __sprint_symbol+0x9c/0x1c0 kernel/kallsyms.c:363 symbol_string+0x14c/0x370 lib/vsprintf.c:969 pointer+0x185/0x970 lib/vsprintf.c:2226 vsnprintf+0x5b2/0x14f0 lib/vsprintf.c:2624 vscnprintf+0x29/0x80 lib/vsprintf.c:2723 vprintk_store+0x44/0x4a0 kernel/printk/printk.c:1942 vprintk_emit+0x139/0x770 kernel/printk/printk.c:2003 vprintk_func+0x8f/0x1a6 kernel/printk/printk_safe.c:393 printk+0xba/0xed kernel/printk/printk.c:2070 show_ip+0x22/0x30 arch/x86/kernel/dumpstack.c:124 show_iret_regs+0x10/0x32 arch/x86/kernel/dumpstack.c:131 __show_regs+0x18/0x50 arch/x86/kernel/process_64.c:72 show_trace_log_lvl+0x255/0x2b4 arch/x86/kernel/dumpstack.c:274 show_regs arch/x86/kernel/dumpstack.c:447 [inline] __die_body arch/x86/kernel/dumpstack.c:393 [inline] __die+0x51/0x90 arch/x86/kernel/dumpstack.c:407 no_context+0x56b/0x9f0 arch/x86/mm/fault.c:695 __bad_area_nosemaphore+0xa9/0x480 arch/x86/mm/fault.c:789 do_user_addr_fault+0x8ce/0xd00 arch/x86/mm/fault.c:1258 handle_page_fault arch/x86/mm/fault.c:1365 [inline] exc_page_fault+0xab/0x170 arch/x86/mm/fault.c:1418 asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:542 RIP: 0010:do_syscall_32_irqs_on+0x3f/0x60 arch/x86/entry/common.c:428 Code: 00 00 00 00 00 00 00 00 00 00 0
Re: [qemu] boot failed: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> Arnd, > I'm looking at the pl001_dma_probe(), I think we could make it more robust if > it > uses IS_ERR_OR_NULL(chan) instead of IS_ERR(). Should I send a patch for it? I > suppose looking at the comment header for dma_request_chan() it does say > return > chan ptr or error ptr. Sorry I missed that. > > > Vinod, > It looks like the only fix for dmaengine for the patch is where Arnd pointed > out > as far as I can tell after auditing it. Let me know how you want to handle > this. > Thanks! This proposed fix patch applied on top of linux next ( 20200706 tag ) and boot test PASS. The reported problem got fixed. Reported-by: Naresh Kamboju Tested-by: Naresh Kamboju > > diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c > index 0d6529eff66f..48e159e83cf5 100644 > --- a/drivers/dma/dmaengine.c > +++ b/drivers/dma/dmaengine.c > @@ -852,7 +852,7 @@ struct dma_chan *dma_request_chan(struct device *dev, > const > char *name) > mutex_lock(&dma_list_mutex); > if (list_empty(&dma_device_list)) { > mutex_unlock(&dma_list_mutex); > - return NULL; > + return ERR_PTR(-ENODEV); > } > > list_for_each_entry_safe(d, _d, &dma_device_list, global_node) { ref: https://lkft.validation.linaro.org/scheduler/job/1542630#L510 -- Linaro LKFT https://lkft.linaro.org
Re: [qemu] boot failed: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
On 7/6/2020 8:24 AM, Arnd Bergmann wrote: On Mon, Jul 6, 2020 at 5:01 PM Dave Jiang wrote: On 7/6/2020 5:53 AM, Arnd Bergmann wrote: On Mon, Jul 6, 2020 at 1:03 PM Naresh Kamboju wrote: Arnd, I'm looking at the pl001_dma_probe(), I think we could make it more robust if it uses IS_ERR_OR_NULL(chan) instead of IS_ERR(). Should I send a patch for it? I suppose looking at the comment header for dma_request_chan() it does say return chan ptr or error ptr. Sorry I missed that. No. IS_ERR_OR_NULL() is almost always a mistake. A function should either return NULL on error, or it should return an error code, but should not be able to return either. Fair enough. Have you checked all the other 'return NULL' statements in your patch to ensure that they never return error pointers? Yeah I looked over the rest of them. The ones that are returning NULL as far as I can tell are expected to return NULL. Arnd
Re: [qemu] boot failed: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
On Mon, Jul 6, 2020 at 5:01 PM Dave Jiang wrote: > On 7/6/2020 5:53 AM, Arnd Bergmann wrote: > > On Mon, Jul 6, 2020 at 1:03 PM Naresh Kamboju > > wrote: > > Arnd, > I'm looking at the pl001_dma_probe(), I think we could make it more robust if > it > uses IS_ERR_OR_NULL(chan) instead of IS_ERR(). Should I send a patch for it? I > suppose looking at the comment header for dma_request_chan() it does say > return > chan ptr or error ptr. Sorry I missed that. No. IS_ERR_OR_NULL() is almost always a mistake. A function should either return NULL on error, or it should return an error code, but should not be able to return either. Have you checked all the other 'return NULL' statements in your patch to ensure that they never return error pointers? Arnd
Re: [qemu] boot failed: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
On 06-07-20, 07:33, Dave Jiang wrote: > > I don't see anything suspicious in dmaengine drivers, but there is a > > recent series > > from Dave Jiang that might explain it. Could you try reverting commit > > deb9541f5052 ("dmaengine: check device and channel list for empty")? > > > > I think the broken change is this one: > > > > @@ -819,6 +850,11 @@ struct dma_chan *dma_request_chan(struct device > > *dev, const char *name) > > > > /* Try to find the channel via the DMA filter map(s) */ > > mutex_lock(&dma_list_mutex); > > + if (list_empty(&dma_device_list)) { > > + mutex_unlock(&dma_list_mutex); > > + return NULL; > > + } > > + > > list_for_each_entry_safe(d, _d, &dma_device_list, global_node) { > > dma_cap_mask_t mask; > > const struct dma_slave_map *map = dma_filter_match(d, > > name, dev); > > > > which needs to return an error code like -ENODEV instead of NULL. There > > may be other changes in the same patch that introduce the same bug > > elsewhere. > > > > Arnd > > > > Vinod, > Do you want a diff fix or a revision of the patch for the fix? Diff fix please -- ~Vinod
Re: [qemu] boot failed: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
On 7/6/2020 5:53 AM, Arnd Bergmann wrote: On Mon, Jul 6, 2020 at 1:03 PM Naresh Kamboju wrote: While booting qemu_arm64 and qemu_arm with Linux version 5.8.0-rc3-next-20200706 the kernel panic noticed due to kernel NULL pointer dereference. metadata: git branch: master git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git git commit: 5680d14d59bddc8bcbc5badf00dbbd4374858497 git describe: next-20200706 make_kernelversion: 5.8.0-rc3 kernel-config: https://builds.tuxbuild.com/Glr-Ql1wbp3qN3cnHogyNA/kernel.config qemu arm64 boot crash log, [0.972053] Unable to handle kernel NULL pointer dereference at virtual address [0.975301] Mem abort info: [0.976316] ESR = 0x9604 [0.977378] EC = 0x25: DABT (current EL), IL = 32 bits [0.979363] SET = 0, FnV = 0 [0.980458] EA = 0, S1PTW = 0 [0.981583] Data abort info: [0.982634] ISV = 0, ISS = 0x0004 [0.984213] CM = 0, WnR = 0 [0.985260] [] user address but active_mm is swapper [0.987600] Internal error: Oops: 9604 [#1] PREEMPT SMP [0.989557] Modules linked in: [0.990671] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc3-next-20200706 #1 [0.993711] Hardware name: linux,dummy-virt (DT) [0.995708] pstate: 0005 (nzcv daif -PAN -UAO BTYPE=--) [0.998168] pc : pl011_dma_probe+0x90/0x360 This is the code from you vmlinux file: 8000107233e4: b90087e2str w2, [sp, #132] 8000107233e8: 97fcf14cbl 80001065f918 8000107233ec: aa0003f4mov x20, x0 8000107233f0: b140041fcmn x0, #0x1, lsl #12 8000107233f4: 54000488b.hi800010723484 // b.pmore 8000107233f8: f9400280ldr x0, [x20] 8000107233fc: f9409c02ldr x2, [x0, #312] 800010723400: b482cbz x2, 800010723410 It's the "ldr x0, [x20]" dereferencing 'chan' in pl011_dma_probe() after checking it for an error value. However it's a NULL pointer, not an error pointer, indicating that there is a bug in the dmaengine driver that you use here, or in the dmaengine core code. Arnd, I'm looking at the pl001_dma_probe(), I think we could make it more robust if it uses IS_ERR_OR_NULL(chan) instead of IS_ERR(). Should I send a patch for it? I suppose looking at the comment header for dma_request_chan() it does say return chan ptr or error ptr. Sorry I missed that. Vinod, It looks like the only fix for dmaengine for the patch is where Arnd pointed out as far as I can tell after auditing it. Let me know how you want to handle this. Thanks! diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c index 0d6529eff66f..48e159e83cf5 100644 --- a/drivers/dma/dmaengine.c +++ b/drivers/dma/dmaengine.c @@ -852,7 +852,7 @@ struct dma_chan *dma_request_chan(struct device *dev, const char *name) mutex_lock(&dma_list_mutex); if (list_empty(&dma_device_list)) { mutex_unlock(&dma_list_mutex); - return NULL; + return ERR_PTR(-ENODEV); } list_for_each_entry_safe(d, _d, &dma_device_list, global_node) { I don't see anything suspicious in dmaengine drivers, but there is a recent series from Dave Jiang that might explain it. Could you try reverting commit deb9541f5052 ("dmaengine: check device and channel list for empty")? I think the broken change is this one: @@ -819,6 +850,11 @@ struct dma_chan *dma_request_chan(struct device *dev, const char *name) /* Try to find the channel via the DMA filter map(s) */ mutex_lock(&dma_list_mutex); + if (list_empty(&dma_device_list)) { + mutex_unlock(&dma_list_mutex); + return NULL; + } + list_for_each_entry_safe(d, _d, &dma_device_list, global_node) { dma_cap_mask_t mask; const struct dma_slave_map *map = dma_filter_match(d, name, dev); which needs to return an error code like -ENODEV instead of NULL. There may be other changes in the same patch that introduce the same bug elsewhere. Arnd
Re: [qemu] boot failed: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
On 7/6/2020 5:53 AM, Arnd Bergmann wrote: On Mon, Jul 6, 2020 at 1:03 PM Naresh Kamboju wrote: While booting qemu_arm64 and qemu_arm with Linux version 5.8.0-rc3-next-20200706 the kernel panic noticed due to kernel NULL pointer dereference. metadata: git branch: master git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git git commit: 5680d14d59bddc8bcbc5badf00dbbd4374858497 git describe: next-20200706 make_kernelversion: 5.8.0-rc3 kernel-config: https://builds.tuxbuild.com/Glr-Ql1wbp3qN3cnHogyNA/kernel.config qemu arm64 boot crash log, [0.972053] Unable to handle kernel NULL pointer dereference at virtual address [0.975301] Mem abort info: [0.976316] ESR = 0x9604 [0.977378] EC = 0x25: DABT (current EL), IL = 32 bits [0.979363] SET = 0, FnV = 0 [0.980458] EA = 0, S1PTW = 0 [0.981583] Data abort info: [0.982634] ISV = 0, ISS = 0x0004 [0.984213] CM = 0, WnR = 0 [0.985260] [] user address but active_mm is swapper [0.987600] Internal error: Oops: 9604 [#1] PREEMPT SMP [0.989557] Modules linked in: [0.990671] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc3-next-20200706 #1 [0.993711] Hardware name: linux,dummy-virt (DT) [0.995708] pstate: 0005 (nzcv daif -PAN -UAO BTYPE=--) [0.998168] pc : pl011_dma_probe+0x90/0x360 This is the code from you vmlinux file: 8000107233e4: b90087e2str w2, [sp, #132] 8000107233e8: 97fcf14cbl 80001065f918 8000107233ec: aa0003f4mov x20, x0 8000107233f0: b140041fcmn x0, #0x1, lsl #12 8000107233f4: 54000488b.hi800010723484 // b.pmore 8000107233f8: f9400280ldr x0, [x20] 8000107233fc: f9409c02ldr x2, [x0, #312] 800010723400: b482cbz x2, 800010723410 It's the "ldr x0, [x20]" dereferencing 'chan' in pl011_dma_probe() after checking it for an error value. However it's a NULL pointer, not an error pointer, indicating that there is a bug in the dmaengine driver that you use here, or in the dmaengine core code. I don't see anything suspicious in dmaengine drivers, but there is a recent series from Dave Jiang that might explain it. Could you try reverting commit deb9541f5052 ("dmaengine: check device and channel list for empty")? I think the broken change is this one: @@ -819,6 +850,11 @@ struct dma_chan *dma_request_chan(struct device *dev, const char *name) /* Try to find the channel via the DMA filter map(s) */ mutex_lock(&dma_list_mutex); + if (list_empty(&dma_device_list)) { + mutex_unlock(&dma_list_mutex); + return NULL; + } + list_for_each_entry_safe(d, _d, &dma_device_list, global_node) { dma_cap_mask_t mask; const struct dma_slave_map *map = dma_filter_match(d, name, dev); which needs to return an error code like -ENODEV instead of NULL. There may be other changes in the same patch that introduce the same bug elsewhere. Arnd Vinod, Do you want a diff fix or a revision of the patch for the fix?
Re: [qemu] boot failed: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
On Mon, Jul 6, 2020 at 1:03 PM Naresh Kamboju wrote: > > While booting qemu_arm64 and qemu_arm with Linux version > 5.8.0-rc3-next-20200706 > the kernel panic noticed due to kernel NULL pointer dereference. > > metadata: > git branch: master > git repo: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > git commit: 5680d14d59bddc8bcbc5badf00dbbd4374858497 > git describe: next-20200706 > make_kernelversion: 5.8.0-rc3 > kernel-config: > https://builds.tuxbuild.com/Glr-Ql1wbp3qN3cnHogyNA/kernel.config > > qemu arm64 boot crash log, > > [0.972053] Unable to handle kernel NULL pointer dereference at > virtual address > [0.975301] Mem abort info: > [0.976316] ESR = 0x9604 > [0.977378] EC = 0x25: DABT (current EL), IL = 32 bits > [0.979363] SET = 0, FnV = 0 > [0.980458] EA = 0, S1PTW = 0 > [0.981583] Data abort info: > [0.982634] ISV = 0, ISS = 0x0004 > [0.984213] CM = 0, WnR = 0 > [0.985260] [] user address but active_mm is swapper > [0.987600] Internal error: Oops: 9604 [#1] PREEMPT SMP > [0.989557] Modules linked in: > [0.990671] CPU: 2 PID: 1 Comm: swapper/0 Not tainted > 5.8.0-rc3-next-20200706 #1 > [0.993711] Hardware name: linux,dummy-virt (DT) > [0.995708] pstate: 0005 (nzcv daif -PAN -UAO BTYPE=--) > [0.998168] pc : pl011_dma_probe+0x90/0x360 This is the code from you vmlinux file: 8000107233e4: b90087e2str w2, [sp, #132] 8000107233e8: 97fcf14cbl 80001065f918 8000107233ec: aa0003f4mov x20, x0 8000107233f0: b140041fcmn x0, #0x1, lsl #12 8000107233f4: 54000488b.hi800010723484 // b.pmore 8000107233f8: f9400280ldr x0, [x20] 8000107233fc: f9409c02ldr x2, [x0, #312] 800010723400: b482cbz x2, 800010723410 It's the "ldr x0, [x20]" dereferencing 'chan' in pl011_dma_probe() after checking it for an error value. However it's a NULL pointer, not an error pointer, indicating that there is a bug in the dmaengine driver that you use here, or in the dmaengine core code. I don't see anything suspicious in dmaengine drivers, but there is a recent series from Dave Jiang that might explain it. Could you try reverting commit deb9541f5052 ("dmaengine: check device and channel list for empty")? I think the broken change is this one: @@ -819,6 +850,11 @@ struct dma_chan *dma_request_chan(struct device *dev, const char *name) /* Try to find the channel via the DMA filter map(s) */ mutex_lock(&dma_list_mutex); + if (list_empty(&dma_device_list)) { + mutex_unlock(&dma_list_mutex); + return NULL; + } + list_for_each_entry_safe(d, _d, &dma_device_list, global_node) { dma_cap_mask_t mask; const struct dma_slave_map *map = dma_filter_match(d, name, dev); which needs to return an error code like -ENODEV instead of NULL. There may be other changes in the same patch that introduce the same bug elsewhere. Arnd
[qemu] boot failed: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
While booting qemu_arm64 and qemu_arm with Linux version 5.8.0-rc3-next-20200706 the kernel panic noticed due to kernel NULL pointer dereference. metadata: git branch: master git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git git commit: 5680d14d59bddc8bcbc5badf00dbbd4374858497 git describe: next-20200706 make_kernelversion: 5.8.0-rc3 kernel-config: https://builds.tuxbuild.com/Glr-Ql1wbp3qN3cnHogyNA/kernel.config qemu arm64 boot crash log, [0.972053] Unable to handle kernel NULL pointer dereference at virtual address [0.975301] Mem abort info: [0.976316] ESR = 0x9604 [0.977378] EC = 0x25: DABT (current EL), IL = 32 bits [0.979363] SET = 0, FnV = 0 [0.980458] EA = 0, S1PTW = 0 [0.981583] Data abort info: [0.982634] ISV = 0, ISS = 0x0004 [0.984213] CM = 0, WnR = 0 [0.985260] [] user address but active_mm is swapper [0.987600] Internal error: Oops: 9604 [#1] PREEMPT SMP [0.989557] Modules linked in: [0.990671] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc3-next-20200706 #1 [0.993711] Hardware name: linux,dummy-virt (DT) [0.995708] pstate: 0005 (nzcv daif -PAN -UAO BTYPE=--) [0.998168] pc : pl011_dma_probe+0x90/0x360 [1.15] lr : pl011_dma_probe+0x84/0x360 [1.001827] sp : 800011f4b880 [1.003294] x29: 800011f4b880 x28: fada5800 [1.005562] x27: 800011e057d8 x26: 00020002 [1.007884] x25: 8000110c0ed0 x24: 8000110c0b70 [1.010164] x23: x22: faca8000 [1.012438] x21: faee6000 x20: [1.014724] x19: faee7480 x18: 0002 [1.016977] x17: 1400 x16: 1c00 [1.019270] x15: 0001 x14: 0003a051 [1.021544] x13: x12: 0010 [1.023805] x11: 0004 x10: 0101010101010101 [1.026091] x9 : fffc x8 : 7f7f7f7f7f7f7f7f [1.028354] x7 : fefefeff646c606d x6 : 0a0c0c1680808080 [1.030645] x5 : 160c0c0a x4 : [1.032887] x3 : 800011de1878 x2 : [1.035179] x1 : 5d22d5f0b315de00 x0 : [1.037439] Call trace: [1.038640] pl011_dma_probe+0x90/0x360 [1.040281] pl011_startup+0x268/0x2f0 [1.041935] uart_startup.part.0+0x124/0x2d8 [1.043777] uart_port_activate+0x60/0x98 [1.045483] tty_port_open+0x90/0x248 [1.047163] uart_open+0x1c/0x30 [1.048568] tty_open+0xf4/0x478 [1.049973] chrdev_open+0xa4/0x1a0 [1.051491] do_dentry_open+0x12c/0x398 [1.053156] vfs_open+0x2c/0x38 [1.054551] path_openat+0x86c/0xdf0 [1.056103] do_filp_open+0x78/0x100 [1.057651] do_sys_openat2+0x1e4/0x2a0 [1.059410] do_sys_open+0x58/0xa0 [1.060866] console_on_rootfs+0x24/0x68 [1.062577] kernel_init_freeable+0x1f4/0x254 [1.064450] kernel_init+0x14/0x110 [1.065972] ret_from_fork+0x10/0x34 [1.067504] Code: 97fcf14c aa0003f4 b140041f 54000488 (f9400280) [1.070107] ---[ end trace 8001204d6659f3e5 ]--- [1.072104] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [1.074875] SMP: stopping secondary CPUs [1.076613] Kernel Offset: disabled [1.078123] CPU features: 0x240002,20002004 [1.079916] Memory Limit: none [1.081255] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b ]--- Full test log, https://lkft.validation.linaro.org/scheduler/job/1542193#L510 qemu command, /usr/bin/qemu-system-aarch64 -cpu host -machine virt-2.10,accel=kvm -nographic -net nic,model=virtio,macaddr=BA:DD:AD:CC:09:05 -net tap -m 2048 -monitor none -kernel /kernel/Image --append "console=ttyAMA0 root=/dev/vda rw" -hda /rootfs/rpb-console-image-lkft-juno-20200521172852-2689.rootfs.ext4 -m 4096 -smp 4 -nographic -drive format=qcow2,file=lava-guest.qcow2,media=disk,if=virtio,id=lavatest -- Linaro LKFT https://lkft.linaro.org
BUG: unable to handle kernel NULL pointer dereference in bpf_prog_ADDR_L
Hello, syzbot found the following crash on: HEAD commit:cb8e59cc Merge git://git.kernel.org/pub/scm/linux/kernel/g.. git tree: bpf-next console output: https://syzkaller.appspot.com/x/log.txt?x=1446cfd310 kernel config: https://syzkaller.appspot.com/x/.config?x=a16ddbc78955e3a9 dashboard link: https://syzkaller.appspot.com/bug?extid=a4c6e533af740abd3922 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+a4c6e533af740abd3...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 85748067 P4D 85748067 PUD 61918067 PMD 0 Oops: [#1] PREEMPT SMP KASAN CPU: 0 PID: 4768 Comm: syz-executor.0 Not tainted 5.7.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:bpf_prog_6df1c5236f32720a_L+0x1f/0xa18 Code: cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 55 48 89 e5 48 81 ec 00 00 00 00 53 41 55 41 56 41 57 6a 00 31 c0 48 8b 7f 28 <48> 8b 7f 00 8b bf 00 01 00 00 5b 41 5f 41 5e 41 5d 5b c9 c3 cc cc RSP: 0018:c90001ee7ac0 EFLAGS: 00010246 RAX: RBX: dc00 RCX: c900022ea000 RDX: 0230 RSI: c9cb8038 RDI: RBP: c90001ee7ae8 R08: 88805dc5e200 R09: 0001 R10: R11: R12: c9cb8000 R13: dc00 R14: 0001 R15: 88805dc5e200 FS: 7fc83e30f700() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 8c0f4000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0600 Call Trace: bpf_prog_run_xdp include/linux/filter.h:734 [inline] bpf_test_run+0x226/0xc70 net/bpf/test_run.c:47 bpf_prog_test_run_xdp+0x2ca/0x510 net/bpf/test_run.c:507 bpf_prog_test_run kernel/bpf/syscall.c:2998 [inline] __do_sys_bpf+0x28ce/0x4a80 kernel/bpf/syscall.c:4138 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x45cb29 Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fc83e30ec78 EFLAGS: 0246 ORIG_RAX: 0141 RAX: ffda RBX: 004dade0 RCX: 0045cb29 RDX: 0040 RSI: 2040 RDI: 000a RBP: 0078bfa0 R08: R09: R10: R11: 0246 R12: R13: 005d R14: 004c32db R15: 7fc83e30f6d4 Modules linked in: CR2: ---[ end trace 6c5d2c7e681a670d ]--- RIP: 0010:bpf_prog_6df1c5236f32720a_L+0x1f/0xa18 Code: cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 55 48 89 e5 48 81 ec 00 00 00 00 53 41 55 41 56 41 57 6a 00 31 c0 48 8b 7f 28 <48> 8b 7f 00 8b bf 00 01 00 00 5b 41 5f 41 5e 41 5d 5b c9 c3 cc cc RSP: 0018:c90001ee7ac0 EFLAGS: 00010246 RAX: RBX: dc00 RCX: c900022ea000 RDX: 0230 RSI: c9cb8038 RDI: RBP: c90001ee7ae8 R08: 88805dc5e200 R09: 0001 R10: R11: R12: c9cb8000 R13: dc00 R14: 0001 R15: 88805dc5e200 FS: 7fc83e30f700() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 8c0f4000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0600 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
BUG: unable to handle kernel NULL pointer dereference in __syscall_return_slowpath
Hello, syzbot found the following crash on: HEAD commit:4e99b321 Merge tag 'nfs-for-5.8-2' of git://git.linux-nfs... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=116abdd310 kernel config: https://syzkaller.appspot.com/x/.config?x=bf3aec367b9ab569 dashboard link: https://syzkaller.appspot.com/bug?extid=95910cea1a7ad8850a0f compiler: gcc (GCC) 10.1.0-syz 20200507 userspace arch: i386 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1702075510 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+95910cea1a7ad8850...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: 000f #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP KASAN CPU: 0 PID: 8079 Comm: systemd-udevd Not tainted 5.8.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__syscall_return_slowpath+0x0/0x280 arch/x86/entry/common.c:309 Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 RSP: 0018:c90004cd7f38 EFLAGS: 00010283 RAX: 000f RBX: 0002 RCX: RDX: dc00 RSI: 81bc66f2 RDI: c90004cd7f58 RBP: c90004cd7f58 R08: R09: 8880ae636cdb R10: R11: R12: R13: R14: R15: FS: 7f934b3b78c0() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 000f CR3: 8ebc4000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: do_syscall_64+0x6c/0xe0 arch/x86/entry/common.c:368 entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: kernel NULL pointer dereference, address: #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#2] PREEMPT SMP KASAN CPU: 0 PID: 8079 Comm: systemd-udevd Not tainted 5.8.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:in_gate_area_no_mm+0x0/0x6a arch/x86/entry/vsyscall/vsyscall_64.c:343 Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 RSP: 0018:c90004cd7478 EFLAGS: 00010093 RAX: RBX: c90004cd7518 RCX: 8169f800 RDX: 888091d90300 RSI: 8169f82b RDI: 7f934a4fe840 RBP: 7f934a4fe840 R08: c90004cd7628 R09: 8c8c8109 R10: 7f934a4fe840 R11: R12: c90004cd7628 R13: 0001 R14: 7f934a4fe840 R15: c90004cd7538 FS: 7f934b3b78c0() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 8ebc4000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: is_kernel include/linux/kallsyms.h:43 [inline] is_ksym_addr include/linux/kallsyms.h:49 [inline] kallsyms_lookup+0xc3/0x2e0 kernel/kallsyms.c:290 __sprint_symbol+0x9c/0x1c0 kernel/kallsyms.c:363 symbol_string+0x14c/0x370 lib/vsprintf.c:969 pointer+0x185/0x970 lib/vsprintf.c:2226 vsnprintf+0x5b2/0x14f0 lib/vsprintf.c:2624 vscnprintf+0x29/0x80 lib/vsprintf.c:2723 vprintk_store+0x44/0x4a0 kernel/printk/printk.c:1942 vprintk_emit+0x139/0x770 kernel/printk/printk.c:2003 vprintk_func+0x8f/0x1a6 kernel/printk/printk_safe.c:393 printk+0xba/0xed kernel/printk/printk.c:2070 show_ip+0x22/0x30 arch/x86/kernel/dumpstack.c:124 show_iret_regs+0x10/0x32 arch/x86/kernel/dumpstack.c:131 __show_regs+0x18/0x50 arch/x86/kernel/process_64.c:72 show_trace_log_lvl+0x255/0x2b4 arch/x86/kernel/dumpstack.c:274 show_regs arch/x86/kernel/dumpstack.c:447 [inline] __die_body arch/x86/kernel/dumpstack.c:393 [inline] __die+0x51/0x90 arch/x86/kernel/dumpstack.c:407 no_context+0x56b/0x9f0 arch/x86/mm/fault.c:695 __bad_area_nosemaphore+0xa9/0x480 arch/x86/mm/fault.c:789 do_user_addr_fault arch/x86/mm/fault.c:1268 [inline] handle_page_fault arch/x86/mm/fault.c:1365 [inline] exc_page_fault+0xc29/0x14c0 arch/x86/mm/fault.c:1418 asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:565 RIP: 0010:__syscall_return_slowpath+0x0/0x280 arch/x86/entry/common.c:309 Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 0
Re: BUG: unable to handle kernel NULL pointer dereference in __syscall_return_slowpath
On Mon, Jun 29, 2020 at 09:31:16AM -0700, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:4e99b321 Merge tag 'nfs-for-5.8-2' of git://git.linux-nfs... > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=116abdd310 > kernel config: https://syzkaller.appspot.com/x/.config?x=bf3aec367b9ab569 > dashboard link: https://syzkaller.appspot.com/bug?extid=95910cea1a7ad8850a0f > compiler: gcc (GCC) 10.1.0-syz 20200507 > userspace arch: i386 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1702075510 Looks like ioctl$FBIOPUT_VSCREENINFO on /dev/fb0 striking again. There are like 20-30 open syzbot reports for this. See https://lkml.kernel.org/lkml/ff323f05a0531...@google.com/T/#u for some previous discussion. #syz dup: general protection fault in syscall_return_slowpath
Re: BUG: unable to handle kernel NULL pointer dereference in generic_perform_write (2)
Hello, syzbot has tested the proposed patch and the reproducer did not trigger crash: Reported-and-tested-by: syzbot+bca9799bf12925619...@syzkaller.appspotmail.com Tested on: commit: 5749fe5a ext4: avoid race conditions when remounting with .. git tree: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git kernel config: https://syzkaller.appspot.com/x/.config?x=175fcaead7a60c3f dashboard link: https://syzkaller.appspot.com/bug?extid=bca9799bf129256190da compiler: gcc (GCC) 9.0.0 20181231 (experimental) Note: testing is done by a robot and is best-effort only.
Re: BUG: unable to handle kernel NULL pointer dereference in generic_perform_write (2)
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 5749fe5af3db176659978718ddaecebb450cdb6b
Re: BUG: unable to handle kernel NULL pointer dereference in generic_perform_write (2)
Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: BUG: unable to handle kernel NULL pointer dereference in generic_perform_write BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD a3819067 P4D a3819067 PUD a2ea0067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 1 PID: 9214 Comm: syz-executor.1 Not tainted 5.6.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:c90006d1fa38 EFLAGS: 00010246 RAX: 883cb0a0 RBX: RCX: 0001 RDX: RSI: 888082b89a60 RDI: 88808a414a80 RBP: 888082b89a60 R08: R09: c90006d1fac0 R10: 888072cd6607 R11: ed100e59acc0 R12: 0001 R13: R14: R15: c90006d1fd18 FS: 7f310f3f3700() GS:8880ae70() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 904f1000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: generic_perform_write+0x20a/0x4e0 mm/filemap.c:3302 ext4_buffered_write_iter+0x1f7/0x450 fs/ext4/file.c:270 ext4_file_write_iter+0x1ec/0x13f0 fs/ext4/file.c:642 call_write_iter include/linux/fs.h:1907 [inline] new_sync_write+0x4a2/0x700 fs/read_write.c:484 __vfs_write+0xc9/0x100 fs/read_write.c:497 vfs_write+0x268/0x5d0 fs/read_write.c:559 ksys_write+0x12d/0x250 fs/read_write.c:612 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x45c889 Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f310f3f2c78 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: 7f310f3f36d4 RCX: 0045c889 RDX: 0001 RSI: 2080 RDI: 0003 RBP: 0076bfa0 R08: R09: R10: R11: 0246 R12: R13: 0cdc R14: 004cf042 R15: 0076bfac Modules linked in: CR2: ---[ end trace ff42a65b331528ba ]--- RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:c90006d1fa38 EFLAGS: 00010246 RAX: 883cb0a0 RBX: RCX: 0001 RDX: RSI: 888082b89a60 RDI: 88808a414a80 RBP: 888082b89a60 R08: R09: c90006d1fac0 R10: 888072cd6607 R11: ed100e59acc0 R12: 0001 R13: R14: R15: c90006d1fd18 FS: 7f310f3f3700() GS:8880ae70() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0076c061 CR3: 904f1000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Tested on: commit: 5b8b9d0c Merge branch 'akpm' (patches from Andrew) git tree: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git console output: https://syzkaller.appspot.com/x/log.txt?x=158b23ca10 kernel config: https://syzkaller.appspot.com/x/.config?x=23c5a352e32a1944 dashboard link: https://syzkaller.appspot.com/bug?extid=bca9799bf129256190da compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Re: BUG: unable to handle kernel NULL pointer dereference in generic_perform_write (2)
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 5b8b9d0c6d0e0f1993c6c56deaf9646942c49d94
Re: BUG: unable to handle kernel NULL pointer dereference in generic_perform_write (2)
Hello, syzbot tried to test the proposed patch but build/boot failed: syzkaller build failed: failed to run ["make" "target"]: exit status 2 GOOS=linux GOARCH=amd64 go install ./syz-fuzzer # github.com/google/syzkaller/sys/netbsd/gen sys/netbsd/gen/amd64.go:41:58: undefined: Field sys/netbsd/gen/amd64.go:44:10: undefined: Ref sys/netbsd/gen/amd64.go:45:59: undefined: Ref sys/netbsd/gen/amd64.go:46:70: undefined: Field sys/netbsd/gen/amd64.go:49:66: undefined: Field sys/netbsd/gen/amd64.go:54:60: undefined: Field sys/netbsd/gen/amd64.go:58:66: undefined: Field sys/netbsd/gen/amd64.go:62:68: undefined: Field sys/netbsd/gen/amd64.go:68:62: undefined: Field sys/netbsd/gen/amd64.go:72:59: undefined: Ref sys/netbsd/gen/amd64.go:72:59: too many errors # github.com/google/syzkaller/sys/akaros/gen sys/akaros/gen/amd64.go:23:63: undefined: Field sys/akaros/gen/amd64.go:26:69: undefined: Field sys/akaros/gen/amd64.go:29:56: undefined: Field sys/akaros/gen/amd64.go:34:52: undefined: Field sys/akaros/gen/amd64.go:39:67: undefined: Field sys/akaros/gen/amd64.go:43:54: undefined: Field sys/akaros/gen/amd64.go:48:54: undefined: Field sys/akaros/gen/amd64.go:51:64: undefined: Field sys/akaros/gen/amd64.go:56:51: undefined: Field sys/akaros/gen/amd64.go:62:56: undefined: Field sys/akaros/gen/amd64.go:62:56: too many errors # github.com/google/syzkaller/sys/openbsd/gen sys/openbsd/gen/amd64.go:49:55: undefined: Field sys/openbsd/gen/amd64.go:53:10: undefined: Ref sys/openbsd/gen/amd64.go:54:60: undefined: Field sys/openbsd/gen/amd64.go:58:10: undefined: Ref sys/openbsd/gen/amd64.go:59:61: undefined: Field sys/openbsd/gen/amd64.go:63:10: undefined: Ref sys/openbsd/gen/amd64.go:64:60: undefined: Field sys/openbsd/gen/amd64.go:68:10: undefined: Ref sys/openbsd/gen/amd64.go:69:51: undefined: Field sys/openbsd/gen/amd64.go:72:52: undefined: Field sys/openbsd/gen/amd64.go:72:52: too many errors # github.com/google/syzkaller/sys/test/gen sys/test/gen/32_fork_shmem.go:29:55: unknown field 'Attrs' in struct literal of type prog.Syscall sys/test/gen/32_fork_shmem.go:30:45: unknown field 'Attrs' in struct literal of type prog.Syscall sys/test/gen/32_fork_shmem.go:31:50: undefined: Ref sys/test/gen/32_fork_shmem.go:31:60: unknown field 'Attrs' in struct literal of type prog.Syscall sys/test/gen/32_fork_shmem.go:32:53: undefined: Field sys/test/gen/32_fork_shmem.go:34:5: unknown field 'Attrs' in struct literal of type prog.Syscall sys/test/gen/32_fork_shmem.go:35:66: undefined: Ref sys/test/gen/32_fork_shmem.go:36:53: undefined: Field sys/test/gen/32_fork_shmem.go:39:62: undefined: Field sys/test/gen/32_fork_shmem.go:42:48: undefined: Field sys/test/gen/32_fork_shmem.go:42:48: too many errors # github.com/google/syzkaller/sys/freebsd/gen sys/freebsd/gen/386.go:49:76: undefined: Field sys/freebsd/gen/386.go:54:60: undefined: Field sys/freebsd/gen/386.go:58:68: undefined: Field sys/freebsd/gen/386.go:65:67: undefined: Field sys/freebsd/gen/386.go:71:68: undefined: Field sys/freebsd/gen/386.go:77:67: undefined: Field sys/freebsd/gen/386.go:83:67: undefined: Field sys/freebsd/gen/386.go:89:68: undefined: Field sys/freebsd/gen/386.go:95:69: undefined: Field sys/freebsd/gen/386.go:101:85: undefined: Field sys/freebsd/gen/386.go:101:85: too many errors # github.com/google/syzkaller/sys/windows/gen sys/windows/gen/amd64.go:23:51: undefined: Field sys/windows/gen/amd64.go:26:53: undefined: Field sys/windows/gen/amd64.go:29:59: undefined: Field sys/windows/gen/amd64.go:32:75: undefined: Field sys/windows/gen/amd64.go:35:51: undefined: Field sys/windows/gen/amd64.go:45:57: undefined: Field sys/windows/gen/amd64.go:55:85: undefined: Field sys/windows/gen/amd64.go:66:69: undefined: Field sys/windows/gen/amd64.go:77:97: undefined: Field sys/windows/gen/amd64.go:88:89: undefined: Field sys/windows/gen/amd64.go:88:89: too many errors # github.com/google/syzkaller/sys/fuchsia/gen sys/fuchsia/gen/amd64.go:96:45: undefined: Field sys/fuchsia/gen/amd64.go:99:45: undefined: Field sys/fuchsia/gen/amd64.go:103:45: undefined: Field sys/fuchsia/gen/amd64.go:108:45: undefined: Field sys/fuchsia/gen/amd64.go:111:45: undefined: Field sys/fuchsia/gen/amd64.go:114:10: undefined: Ref sys/fuchsia/gen/amd64.go:115:41: undefined: Field sys/fuchsia/gen/amd64.go:117:10: undefined: Ref sys/fuchsia/gen/amd64.go:118:43: undefined: Field sys/fuchsia/gen/amd64.go:121:10: undefined: Ref sys/fuchsia/gen/amd64.go:121:10: too many errors # github.com/google/syzkaller/sys/linux/gen sys/linux/gen/386.go:296:58: undefined: Field sys/linux/gen/386.go:301:10: undefined: Ref sys/linux/gen/386.go:302:62: undefined: Field sys/linux/gen/386.go:307:10: undefined: Ref sys/linux/gen/386.go:308:63: undefined: Field sys/linux/gen/386.go:313:10: undefined: Ref sys/linux/gen/386.go:314:67: undefined: Field sys/linux/gen/386.go:319:10: undefined: Ref sys/linux/gen/386.go:320:63: undefined: Field sys/linux/gen/386.go:325:10: undefined: Ref sys/linux/gen/386.go:325:10: too many errors Makefile:
Re: BUG: unable to handle kernel NULL pointer dereference in generic_perform_write (2)
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 5b8b9d0c6d0e0f1993c6c56deaf9646942c49d94
Re: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 in nilfs_segctor_do_co
> Wondering if it can be reproduced on mainline with c3aab9a0bd91 > ("mm/filemap.c: dont initiate writeback if mapping has no dirty pages") > reverted? For mainline kernels with that commit reverted, this oops actually doesn't occur. Regards, Ryusuke Konishi On Mon, Jun 1, 2020 at 11:40 AM Hillf Danton wrote: > On Mon, 01 Jun 2020 02:49:54 Ryusuke Konishi wrote: > > Hi, > > > > This bug turned out to be caused by set_page_writeback() call for > > segment summary buffers and super root buffers at > > nilfs_segctor_prepare_write(). > > > > set_page_writeback() can call inc_wb_stat(inode_to_wb(inode), > > WB_WRIEBACK) where inode_to_wb(inode) is NULL if inode_attach_wb() is > > not called in advance. To ensure inode_attach_wb() is called, > > mark_buffer_dirty() should be called for those buffers. > > > > The following patch fixes this issue, > > Thanks for sharing your analysis and patch. > > Wondering if it can be reproduced on mainline with c3aab9a0bd91 > ("mm/filemap.c: dont initiate writeback if mapping has no dirty pages") > reverted? If no then we need to update the stable trees. > > Hillf > > > but I got another oops at > > nilfs_segctor_complete_write() during a stress test. So, I'm still > > investigating. > > > > Regards, > > Ryusuke Konishi > > > > === > > diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c > > index 445eef4..f6b5ca8 100644 > > --- a/fs/nilfs2/segment.c > > +++ b/fs/nilfs2/segment.c > > @@ -1650,6 +1650,8 @@ static void nilfs_segctor_prepare_write(struct > > nilfs_sc_info *sci) > > > > list_for_each_entry(bh, &segbuf->sb_segsum_buffers, > > b_assoc_buffers) { > > + set_buffer_uptodate(bh); > > + mark_buffer_dirty(bh); > > if (bh->b_page != bd_page) { > > if (bd_page) { > > lock_page(bd_page); > > @@ -1665,6 +1667,8 @@ static void nilfs_segctor_prepare_write(struct > > nilfs_sc_info *sci) > > b_assoc_buffers) { > > set_buffer_async_write(bh); > > if (bh == segbuf->sb_super_root) { > > + set_buffer_uptodate(bh); > > + mark_buffer_dirty(bh); > > if (bh->b_page != bd_page) { > > lock_page(bd_page); > > clear_page_dirty_for_io(bd_page); > > === > > > > > > On Thu, 30 Apr 2020 08:27:47 -0700, Tom wrote: > > > Thank you! This is very helpful information, and does seem to be a > > > workaround. > > > > > > Like you, I have my home directory on a separate NILFS2 filesystem. As > > > a temporary solution, I removed the line from /etc/fstab for that > > > filesystem and added your dd suggestion along with a manual mount of > > > the home filesystem to /etc/rc.local. /home is now mounted properly > > > at boot with any of the newer kernels I tried. > > > > > > Thanks, > > > Tom > > > > > > On 4/30/20 5:38 AM, Hideki EIRAKU wrote: > > >>> In Msg <874kuapb2s@logand.com>; > > >>> Subject "Re: BUG: unable to handle kernel NULL pointer dereference > > >>> at > > >>> 00a8 in nilfs_segctor_do_construct": > > >>> > > >>>> Tomas Hlavaty writes: > > >>>>>>> 2) Can you mount the corrupted(?) partition from a recent version of > > >>>>>>> kernel ? > > >>>> > > >>>> I tried the following Linux kernel versions: > > >>>> > > >>>> - v4.19 > > >>>> - v5.4 > > >>>> - v5.5.11 > > >>>> > > >>>> and still get the crash > > >> I found conditions to reproduce this issue with Linux 5.7-rc3: > > >> - CONFIG_MEMCG=y *and* CONFIG_BLK_CGROUP=y > > >> - When the NILFS2 file system writes to a device, the device file has > > >>never written by other programs since boot > > >> The following is an example with CONFIG_MEMCG=y and > > >> CONFIG_BLK_CGROUP=y kernel. If you do mkfs and mount it, it works > > >> because the mkfs command has written data to the device file before > > >> mounting
Re: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 in nilfs_segctor_do_co
Hi, This bug turned out to be caused by set_page_writeback() call for segment summary buffers and super root buffers at nilfs_segctor_prepare_write(). set_page_writeback() can call inc_wb_stat(inode_to_wb(inode), WB_WRIEBACK) where inode_to_wb(inode) is NULL if inode_attach_wb() is not called in advance. To ensure inode_attach_wb() is called, mark_buffer_dirty() should be called for those buffers. The following patch fixes this issue, but I got another oops at nilfs_segctor_complete_write() during a stress test. So, I'm still investigating. Regards, Ryusuke Konishi === diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c index 445eef4..f6b5ca8 100644 --- a/fs/nilfs2/segment.c +++ b/fs/nilfs2/segment.c @@ -1650,6 +1650,8 @@ static void nilfs_segctor_prepare_write(struct nilfs_sc_info *sci) list_for_each_entry(bh, &segbuf->sb_segsum_buffers, b_assoc_buffers) { + set_buffer_uptodate(bh); + mark_buffer_dirty(bh); if (bh->b_page != bd_page) { if (bd_page) { lock_page(bd_page); @@ -1665,6 +1667,8 @@ static void nilfs_segctor_prepare_write(struct nilfs_sc_info *sci) b_assoc_buffers) { set_buffer_async_write(bh); if (bh == segbuf->sb_super_root) { + set_buffer_uptodate(bh); + mark_buffer_dirty(bh); if (bh->b_page != bd_page) { lock_page(bd_page); clear_page_dirty_for_io(bd_page); === On Thu, 30 Apr 2020 08:27:47 -0700, Tom wrote: > Thank you! This is very helpful information, and does seem to be a > workaround. > > Like you, I have my home directory on a separate NILFS2 filesystem. As > a temporary solution, I removed the line from /etc/fstab for that > filesystem and added your dd suggestion along with a manual mount of > the home filesystem to /etc/rc.local. /home is now mounted properly > at boot with any of the newer kernels I tried. > > Thanks, > Tom > > On 4/30/20 5:38 AM, Hideki EIRAKU wrote: >>> In Msg <874kuapb2s....@logand.com>; >>> Subject "Re: BUG: unable to handle kernel NULL pointer dereference at >>> 00a8 in nilfs_segctor_do_construct": >>> >>>> Tomas Hlavaty writes: >>>>>>> 2) Can you mount the corrupted(?) partition from a recent version of >>>>>>> kernel ? >>>> >>>> I tried the following Linux kernel versions: >>>> >>>> - v4.19 >>>> - v5.4 >>>> - v5.5.11 >>>> >>>> and still get the crash >> I found conditions to reproduce this issue with Linux 5.7-rc3: >> - CONFIG_MEMCG=y *and* CONFIG_BLK_CGROUP=y >> - When the NILFS2 file system writes to a device, the device file has >>never written by other programs since boot >> The following is an example with CONFIG_MEMCG=y and >> CONFIG_BLK_CGROUP=y kernel. If you do mkfs and mount it, it works >> because the mkfs command has written data to the device file before >> mounting: >> # mkfs -t nilfs2 /dev/sda1 >> mkfs.nilfs2 (nilfs-utils 2.2.7) >> Start writing file system initial data to the device >> Blocksize:4096 Device:/dev/sda1 Device Size:267386880 >> File system initialization succeeded !! >> # mount /dev/sda1 /mnt >> # touch /mnt >> # sync >> # >> Loopback mount seems to be the same - if you do losetup, mkfs and >> mount on a loopback device, it works: >> # losetup /dev/loop0 foo >> # mkfs -t nilfs2 /dev/loop0 >> mkfs.nilfs2 (nilfs-utils 2.2.7) >> Start writing file system initial data to the device >> Blocksize:4096 Device:/dev/loop0 Device Size:267386880 >> File system initialization succeeded !! >> # mount /dev/sda1 /mnt >> # touch /mnt >> # sync >> # >> But if you do mkfs on a file and use mount -o loop, it may fail, >> depending on whether the loopback device assigned by the mount command >> was used or not before mounting: >> # /sbin/mkfs.nilfs2 ./foo >> mkfs.nilfs2 (nilfs-utils 2.2.7) >> Start writing file system initial data to the device >> Blocksize:4096 Device:./foo Device Size:268435456 >> File system initialization succeeded !! >> # mount -o loop ./foo /mnt >> [ 36.371331] NILFS (loop0): segctord starting. Construction interval = >> 5 seconds, CP frequency < 30 seconds >> # touch /mnt >> # sync >> [ 40.252
Re: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 in nilfs_segctor_do_co
Thank you! This is very helpful information, and does seem to be a workaround. Like you, I have my home directory on a separate NILFS2 filesystem. As a temporary solution, I removed the line from /etc/fstab for that filesystem and added your dd suggestion along with a manual mount of the home filesystem to /etc/rc.local. /home is now mounted properly at boot with any of the newer kernels I tried. Thanks, Tom On 4/30/20 5:38 AM, Hideki EIRAKU wrote: In Msg <874kuapb2s@logand.com>; Subject "Re: BUG: unable to handle kernel NULL pointer dereference at 00a8 in nilfs_segctor_do_construct": Tomas Hlavaty writes: 2) Can you mount the corrupted(?) partition from a recent version of kernel ? I tried the following Linux kernel versions: - v4.19 - v5.4 - v5.5.11 and still get the crash I found conditions to reproduce this issue with Linux 5.7-rc3: - CONFIG_MEMCG=y *and* CONFIG_BLK_CGROUP=y - When the NILFS2 file system writes to a device, the device file has never written by other programs since boot The following is an example with CONFIG_MEMCG=y and CONFIG_BLK_CGROUP=y kernel. If you do mkfs and mount it, it works because the mkfs command has written data to the device file before mounting: # mkfs -t nilfs2 /dev/sda1 mkfs.nilfs2 (nilfs-utils 2.2.7) Start writing file system initial data to the device Blocksize:4096 Device:/dev/sda1 Device Size:267386880 File system initialization succeeded !! # mount /dev/sda1 /mnt # touch /mnt # sync # Loopback mount seems to be the same - if you do losetup, mkfs and mount on a loopback device, it works: # losetup /dev/loop0 foo # mkfs -t nilfs2 /dev/loop0 mkfs.nilfs2 (nilfs-utils 2.2.7) Start writing file system initial data to the device Blocksize:4096 Device:/dev/loop0 Device Size:267386880 File system initialization succeeded !! # mount /dev/sda1 /mnt # touch /mnt # sync # But if you do mkfs on a file and use mount -o loop, it may fail, depending on whether the loopback device assigned by the mount command was used or not before mounting: # /sbin/mkfs.nilfs2 ./foo mkfs.nilfs2 (nilfs-utils 2.2.7) Start writing file system initial data to the device Blocksize:4096 Device:./foo Device Size:268435456 File system initialization succeeded !! # mount -o loop ./foo /mnt [ 36.371331] NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds # touch /mnt # sync [ 40.252869] BUG: kernel NULL pointer dereference, address: 00a8 (snip) After reboot, it fails: # mount /dev/sda1 /mnt [ 14.021188] NILFS (sda1): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds # touch /mnt # sync [ 20.576309] BUG: kernel NULL pointer dereference, address: 00a8 (snip) But if you do dummy write to the device file before mounting, it works: # dd if=/dev/sda1 of=/dev/sda1 count=1 1+0 records in 1+0 records out 512 bytes copied, 0.0135982 s, 37.7 kB/s # mount /dev/sda1 /mnt [ 52.604560] NILFS (sda1): mounting unchecked fs [ 52.613335] NILFS (sda1): recovery complete [ 52.613877] NILFS (sda1): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds # touch /mnt # sync # # losetup /dev/loop0 foo # dd if=/dev/loop0 of=/dev/loop0 count=1 1+0 records in 1+0 records out 512 bytes copied, 0.0243797 s, 21.0 kB/s # mount /dev/loop0 /mnt [ 271.915595] NILFS (loop0): mounting unchecked fs [ 272.049603] NILFS (loop0): recovery complete [ 272.049724] NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds # touch /mnt # sync # I think the dummy write is a simple workaround for now, unless mounting NILFS2 at boot time. But I have been using NILFS2 /home for years, I would like to know better workarounds.
Re: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 in nilfs_segctor_do_co
> In Msg <874kuapb2s@logand.com>; >Subject "Re: BUG: unable to handle kernel NULL pointer dereference at > 00a8 in nilfs_segctor_do_construct": > >> Tomas Hlavaty writes: >>>>> 2) Can you mount the corrupted(?) partition from a recent version of >>>>> kernel ? >> >> I tried the following Linux kernel versions: >> >> - v4.19 >> - v5.4 >> - v5.5.11 >> >> and still get the crash I found conditions to reproduce this issue with Linux 5.7-rc3: - CONFIG_MEMCG=y *and* CONFIG_BLK_CGROUP=y - When the NILFS2 file system writes to a device, the device file has never written by other programs since boot The following is an example with CONFIG_MEMCG=y and CONFIG_BLK_CGROUP=y kernel. If you do mkfs and mount it, it works because the mkfs command has written data to the device file before mounting: # mkfs -t nilfs2 /dev/sda1 mkfs.nilfs2 (nilfs-utils 2.2.7) Start writing file system initial data to the device Blocksize:4096 Device:/dev/sda1 Device Size:267386880 File system initialization succeeded !! # mount /dev/sda1 /mnt # touch /mnt # sync # Loopback mount seems to be the same - if you do losetup, mkfs and mount on a loopback device, it works: # losetup /dev/loop0 foo # mkfs -t nilfs2 /dev/loop0 mkfs.nilfs2 (nilfs-utils 2.2.7) Start writing file system initial data to the device Blocksize:4096 Device:/dev/loop0 Device Size:267386880 File system initialization succeeded !! # mount /dev/sda1 /mnt # touch /mnt # sync # But if you do mkfs on a file and use mount -o loop, it may fail, depending on whether the loopback device assigned by the mount command was used or not before mounting: # /sbin/mkfs.nilfs2 ./foo mkfs.nilfs2 (nilfs-utils 2.2.7) Start writing file system initial data to the device Blocksize:4096 Device:./foo Device Size:268435456 File system initialization succeeded !! # mount -o loop ./foo /mnt [ 36.371331] NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds # touch /mnt # sync [ 40.252869] BUG: kernel NULL pointer dereference, address: 00a8 (snip) After reboot, it fails: # mount /dev/sda1 /mnt [ 14.021188] NILFS (sda1): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds # touch /mnt # sync [ 20.576309] BUG: kernel NULL pointer dereference, address: 00a8 (snip) But if you do dummy write to the device file before mounting, it works: # dd if=/dev/sda1 of=/dev/sda1 count=1 1+0 records in 1+0 records out 512 bytes copied, 0.0135982 s, 37.7 kB/s # mount /dev/sda1 /mnt [ 52.604560] NILFS (sda1): mounting unchecked fs [ 52.613335] NILFS (sda1): recovery complete [ 52.613877] NILFS (sda1): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds # touch /mnt # sync # # losetup /dev/loop0 foo # dd if=/dev/loop0 of=/dev/loop0 count=1 1+0 records in 1+0 records out 512 bytes copied, 0.0243797 s, 21.0 kB/s # mount /dev/loop0 /mnt [ 271.915595] NILFS (loop0): mounting unchecked fs [ 272.049603] NILFS (loop0): recovery complete [ 272.049724] NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds # touch /mnt # sync # I think the dummy write is a simple workaround for now, unless mounting NILFS2 at boot time. But I have been using NILFS2 /home for years, I would like to know better workarounds.
Re: BUG: unable to handle kernel NULL pointer dereference in xsk_poll
syzbot has bisected this bug to: commit 77cd0d7b3f257fd0e3096b4fdcff1a7d38e99e10 Author: Magnus Karlsson Date: Wed Aug 14 07:27:17 2019 + xsk: add support for need_wakeup flag in AF_XDP rings bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17848acd60 start commit: a3c0e7b1 Merge tag 'libnvdimm-fixes-5.4-rc1' of git://git... git tree: upstream final crash:https://syzkaller.appspot.com/x/report.txt?x=14448acd60 console output: https://syzkaller.appspot.com/x/log.txt?x=10448acd60 kernel config: https://syzkaller.appspot.com/x/.config?x=6ffbfa7e4a36190f dashboard link: https://syzkaller.appspot.com/bug?extid=a5765ed8cdb1cca4d249 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1096d83560 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=129f15f360 Reported-by: syzbot+a5765ed8cdb1cca4d...@syzkaller.appspotmail.com Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings") For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: BUG: unable to handle kernel NULL pointer dereference in xsk_poll
On Mon, Sep 30, 2019 at 9:17 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: Thank you Mr Syzcaller. I am on it. /Magnus > HEAD commit:a3c0e7b1 Merge tag 'libnvdimm-fixes-5.4-rc1' of git://git... > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=14f0543560 > kernel config: https://syzkaller.appspot.com/x/.config?x=6ffbfa7e4a36190f > dashboard link: https://syzkaller.appspot.com/bug?extid=a5765ed8cdb1cca4d249 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1096d83560 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=129f15f360 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+a5765ed8cdb1cca4d...@syzkaller.appspotmail.com > > IPv6: ADDRCONF(NETDEV_CHANGE): hsr0: link becomes ready > 8021q: adding VLAN 0 to HW filter on device batadv0 > BUG: kernel NULL pointer dereference, address: > #PF: supervisor instruction fetch in kernel mode > #PF: error_code(0x0010) - not-present page > PGD 99226067 P4D 99226067 PUD 8fa47067 PMD 0 > Oops: 0010 [#1] PREEMPT SMP KASAN > CPU: 0 PID: 8719 Comm: syz-executor502 Not tainted 5.3.0+ #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:0x0 > Code: Bad RIP value. > RSP: 0018:88809dd4f848 EFLAGS: 00010246 > RAX: RBX: 88808c06d740 RCX: 11101180db7c > RDX: 0002 RSI: RDI: 88809a190b00 > RBP: 88809dd4f880 R08: 8880921924c0 R09: ed101180db31 > R10: ed101180db30 R11: 88808c06d987 R12: 0002 > R13: 0304 R14: 88809a190b00 R15: > FS: 01b27880() GS:8880ae80() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: ffd6 CR3: a307a000 CR4: 001406f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > xsk_poll+0x1e7/0x5a0 net/xdp/xsk.c:430 > sock_poll+0x15e/0x480 net/socket.c:1256 > vfs_poll include/linux/poll.h:90 [inline] > do_pollfd fs/select.c:859 [inline] > do_poll fs/select.c:907 [inline] > do_sys_poll+0x63c/0xdd0 fs/select.c:1001 > __do_sys_ppoll fs/select.c:1101 [inline] > __se_sys_ppoll fs/select.c:1081 [inline] > __x64_sys_ppoll+0x259/0x310 fs/select.c:1081 > do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x441bd9 > 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 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7ffd48824e98 EFLAGS: 0246 ORIG_RAX: 010f > RAX: ffda RBX: 0003 RCX: 00441bd9 > RDX: RSI: 0006 RDI: 2040 > RBP: 7ffd48824eb0 R08: R09: 01bb > R10: R11: 0246 R12: > R13: 00403170 R14: R15: > Modules linked in: > CR2: > ---[ end trace e262cafe88422aec ]--- > RIP: 0010:0x0 > Code: Bad RIP value. > RSP: 0018:88809dd4f848 EFLAGS: 00010246 > RAX: RBX: 88808c06d740 RCX: 11101180db7c > RDX: 0002 RSI: RDI: 88809a190b00 > RBP: 88809dd4f880 R08: 8880921924c0 R09: ed101180db31 > R10: ed101180db30 R11: 88808c06d987 R12: 0002 > R13: 0304 R14: 88809a190b00 R15: > FS: 01b27880() GS:8880ae80() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: ffd6 CR3: a307a000 CR4: 001406f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > syzbot can test patches for this bug, for details see: > https://goo.gl/tpsmEJ#testing-patches
BUG: unable to handle kernel NULL pointer dereference in xsk_poll
Hello, syzbot found the following crash on: HEAD commit:a3c0e7b1 Merge tag 'libnvdimm-fixes-5.4-rc1' of git://git... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=14f0543560 kernel config: https://syzkaller.appspot.com/x/.config?x=6ffbfa7e4a36190f dashboard link: https://syzkaller.appspot.com/bug?extid=a5765ed8cdb1cca4d249 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1096d83560 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=129f15f360 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+a5765ed8cdb1cca4d...@syzkaller.appspotmail.com IPv6: ADDRCONF(NETDEV_CHANGE): hsr0: link becomes ready 8021q: adding VLAN 0 to HW filter on device batadv0 BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 99226067 P4D 99226067 PUD 8fa47067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 8719 Comm: syz-executor502 Not tainted 5.3.0+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:88809dd4f848 EFLAGS: 00010246 RAX: RBX: 88808c06d740 RCX: 11101180db7c RDX: 0002 RSI: RDI: 88809a190b00 RBP: 88809dd4f880 R08: 8880921924c0 R09: ed101180db31 R10: ed101180db30 R11: 88808c06d987 R12: 0002 R13: 0304 R14: 88809a190b00 R15: FS: 01b27880() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: a307a000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: xsk_poll+0x1e7/0x5a0 net/xdp/xsk.c:430 sock_poll+0x15e/0x480 net/socket.c:1256 vfs_poll include/linux/poll.h:90 [inline] do_pollfd fs/select.c:859 [inline] do_poll fs/select.c:907 [inline] do_sys_poll+0x63c/0xdd0 fs/select.c:1001 __do_sys_ppoll fs/select.c:1101 [inline] __se_sys_ppoll fs/select.c:1081 [inline] __x64_sys_ppoll+0x259/0x310 fs/select.c:1081 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x441bd9 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 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffd48824e98 EFLAGS: 0246 ORIG_RAX: 010f RAX: ffda RBX: 0003 RCX: 00441bd9 RDX: RSI: 0006 RDI: 2040 RBP: 7ffd48824eb0 R08: R09: 01bb R10: R11: 0246 R12: R13: 00403170 R14: R15: Modules linked in: CR2: ---[ end trace e262cafe88422aec ]--- RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:88809dd4f848 EFLAGS: 00010246 RAX: RBX: 88808c06d740 RCX: 11101180db7c RDX: 0002 RSI: RDI: 88809a190b00 RBP: 88809dd4f880 R08: 8880921924c0 R09: ed101180db31 R10: ed101180db30 R11: 88808c06d987 R12: 0002 R13: 0304 R14: 88809a190b00 R15: FS: 01b27880() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: a307a000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: BUG: unable to handle kernel NULL pointer dereference in rds_bind
On 9/16/19 9:49 AM, Cong Wang wrote: On Mon, Sep 16, 2019 at 6:29 AM syzbot wrote: Hello, syzbot found the following crash on: HEAD commit:f4b752a6 mlx4: fix spelling mistake "veify" -> "verify" git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=16cbebe660 kernel config: https://syzkaller.appspot.com/x/.config?x=b89bb446a3faaba4 dashboard link: https://syzkaller.appspot.com/bug?extid=fae39afd2101a17ec624 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10753bc160 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111dfc1160 The bug was bisected to: commit b9a1e627405d68d475a3c1f35e685ccfb5bbe668 Author: Cong Wang Date: Thu Jul 4 00:21:13 2019 + hsr: implement dellink to clean up resources The crash has nothing to do with this commit. It is probably caused by the lack of ->laddr_check in rds_loop_transport. Will have a look. regards, Santosh
Re: BUG: unable to handle kernel NULL pointer dereference in rds_bind
On Mon, Sep 16, 2019 at 6:29 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:f4b752a6 mlx4: fix spelling mistake "veify" -> "verify" > git tree: net > console output: https://syzkaller.appspot.com/x/log.txt?x=16cbebe660 > kernel config: https://syzkaller.appspot.com/x/.config?x=b89bb446a3faaba4 > dashboard link: https://syzkaller.appspot.com/bug?extid=fae39afd2101a17ec624 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10753bc160 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111dfc1160 > > The bug was bisected to: > > commit b9a1e627405d68d475a3c1f35e685ccfb5bbe668 > Author: Cong Wang > Date: Thu Jul 4 00:21:13 2019 + > > hsr: implement dellink to clean up resources The crash has nothing to do with this commit. It is probably caused by the lack of ->laddr_check in rds_loop_transport.
BUG: unable to handle kernel NULL pointer dereference in rds_bind
Hello, syzbot found the following crash on: HEAD commit:f4b752a6 mlx4: fix spelling mistake "veify" -> "verify" git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=16cbebe660 kernel config: https://syzkaller.appspot.com/x/.config?x=b89bb446a3faaba4 dashboard link: https://syzkaller.appspot.com/bug?extid=fae39afd2101a17ec624 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10753bc160 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111dfc1160 The bug was bisected to: commit b9a1e627405d68d475a3c1f35e685ccfb5bbe668 Author: Cong Wang Date: Thu Jul 4 00:21:13 2019 + hsr: implement dellink to clean up resources bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11005fc160 final crash:https://syzkaller.appspot.com/x/report.txt?x=13005fc160 console output: https://syzkaller.appspot.com/x/log.txt?x=15005fc160 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+fae39afd2101a17ec...@syzkaller.appspotmail.com Fixes: b9a1e627405d ("hsr: implement dellink to clean up resources") BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 9fef0067 P4D 9fef0067 PUD 9060d067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 1 PID: 9884 Comm: syz-executor453 Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:8880a7c6fcd8 EFLAGS: 00010246 RAX: dc00 RBX: 8992bfe0 RCX: 86b9b636 RDX: RSI: 8880a7c6fd40 RDI: 897830c0 RBP: 8880a7c6fda8 R08: 888093150558 R09: R10: fbfff134af9f R11: 88809a008040 R12: 888093150080 R13: 897830c0 R14: R15: 8880a7c6fd40 FS: 5738a880() GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 8f04a000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: rds_bind+0x420/0x800 net/rds/bind.c:247 __sys_bind+0x239/0x290 net/socket.c:1647 __do_sys_bind net/socket.c:1658 [inline] __se_sys_bind net/socket.c:1656 [inline] __x64_sys_bind+0x73/0xb0 net/socket.c:1656 do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4412b9 Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 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 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffc7c28b228 EFLAGS: 0246 ORIG_RAX: 0031 RAX: ffda RBX: RCX: 004412b9 RDX: 0010 RSI: 2200 RDI: 0003 RBP: 006cb018 R08: 004002c8 R09: 004002c8 R10: 004002c8 R11: 0246 R12: 00402030 R13: 004020c0 R14: R15: Modules linked in: CR2: ---[ end trace b47a1983319ea52a ]--- RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:8880a7c6fcd8 EFLAGS: 00010246 RAX: dc00 RBX: 8992bfe0 RCX: 86b9b636 RDX: RSI: 8880a7c6fd40 RDI: 897830c0 RBP: 8880a7c6fda8 R08: 888093150558 R09: R10: fbfff134af9f R11: 88809a008040 R12: 888093150080 R13: 897830c0 R14: R15: 8880a7c6fd40 FS: 5738a880() GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 004bf788 CR3: 8f04a000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. For information about bisection process see: https://goo.gl/tpsmEJ#bisection syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
BUG: unable to handle kernel NULL pointer dereference in tc_bind_tclass
Hello, syzbot found the following crash on: HEAD commit:0e5b36bc r8152: adjust the settings of ups flags git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=10e5ad7660 kernel config: https://syzkaller.appspot.com/x/.config?x=67b69b427c3b2dbf dashboard link: https://syzkaller.appspot.com/bug?extid=21b29db13c065852f64b compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16cebbda60 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15fb9d0a60 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+21b29db13c065852f...@syzkaller.appspotmail.com 8021q: adding VLAN 0 to HW filter on device batadv0 BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD a9ba0067 P4D a9ba0067 PUD a7851067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 8672 Comm: syz-executor994 Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:888097fb74d8 EFLAGS: 00010246 RAX: dc00 RBX: 884a7740 RCX: 85b55676 RDX: RSI: 0001 RDI: 8880a4cd7400 RBP: 888097fb75d0 R08: 88808dc2e440 R09: 888097fb7658 R10: ed1012ff6ed9 R11: 888097fb76cf R12: 8880a4cd7400 R13: 0001 R14: 888097fb75a8 R15: 884a7740 FS: 56952880() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 9c578000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: tc_bind_tclass+0x13e/0x2f0 net/sched/sch_api.c:1923 tc_ctl_tclass+0xadb/0xcd0 net/sched/sch_api.c:2059 rtnetlink_rcv_msg+0x463/0xb00 net/core/rtnetlink.c:5223 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5241 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:657 ___sys_sendmsg+0x803/0x920 net/socket.c:2311 __sys_sendmsg+0x105/0x1d0 net/socket.c:2356 __do_sys_sendmsg net/socket.c:2365 [inline] __se_sys_sendmsg net/socket.c:2363 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363 do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x441cd9 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 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffc9938bcf8 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 315f6576616c RCX: 00441cd9 RDX: RSI: 2240 RDI: 0005 RBP: 735f656764697262 R08: 01bb R09: 01bb R10: 01bb R11: 0246 R12: R13: 00403270 R14: R15: Modules linked in: CR2: ---[ end trace d5605e2bdb92fab7 ]--- RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:888097fb74d8 EFLAGS: 00010246 RAX: dc00 RBX: 884a7740 RCX: 85b55676 RDX: RSI: 0001 RDI: 8880a4cd7400 RBP: 888097fb75d0 R08: 88808dc2e440 R09: 888097fb7658 R10: ed1012ff6ed9 R11: 888097fb76cf R12: 8880a4cd7400 R13: 0001 R14: 888097fb75a8 R15: 884a7740 FS: 56952880() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 9c578000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
BUG: unable to handle kernel NULL pointer dereference in rxrpc_unuse_local
Hello, syzbot found the following crash on: HEAD commit:57c722e9 net/tls: swap sk_write_space on close git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=13e6c6ee60 kernel config: https://syzkaller.appspot.com/x/.config?x=a4c9e9f08e9e8960 dashboard link: https://syzkaller.appspot.com/bug?extid=ae09baad492cce05644a compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+ae09baad492cce056...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: 0010 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 8bbd0067 P4D 8bbd0067 PUD 907a2067 PMD 0 Oops: 0002 [#1] PREEMPT SMP KASAN CPU: 0 PID: 11895 Comm: syz-executor.3 Not tainted 5.3.0-rc3+ #157 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:arch_atomic_add_return arch/x86/include/asm/atomic.h:167 [inline] RIP: 0010:arch_atomic_sub_return arch/x86/include/asm/atomic.h:179 [inline] RIP: 0010:atomic_sub_return include/asm-generic/atomic-instrumented.h:160 [inline] RIP: 0010:atomic_dec_return include/linux/atomic-fallback.h:455 [inline] RIP: 0010:rxrpc_unuse_local+0x23/0x70 net/rxrpc/local_object.c:405 Code: 1f 84 00 00 00 00 00 55 48 89 e5 41 54 49 89 fc 53 bb ff ff ff ff e8 4c 1a d7 fa 49 8d 7c 24 10 be 04 00 00 00 e8 8d 09 11 fb 41 0f c1 5c 24 10 bf 01 00 00 00 89 de e8 aa 1b d7 fa 83 fb 01 RSP: 0018:88806ab1fb28 EFLAGS: 00010246 RAX: RBX: RCX: 869b6f43 RDX: 0001 RSI: 0004 RDI: 0010 RBP: 88806ab1fb38 R08: 88805f40a480 R09: ed1010e9310f R10: ed1010e9310e R11: 888087498877 R12: R13: 88805f48cd92 R14: 888087498680 R15: 88805f48d208 FS: 7fe68c1f5700() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0010 CR3: a1353000 CR4: 001406f0 Call Trace: rxrpc_release_sock net/rxrpc/af_rxrpc.c:904 [inline] rxrpc_release+0x47d/0x840 net/rxrpc/af_rxrpc.c:930 __sock_release+0xce/0x280 net/socket.c:590 sock_close+0x1e/0x30 net/socket.c:1268 __fput+0x2ff/0x890 fs/file_table.c:280 fput+0x16/0x20 fs/file_table.c:313 task_work_run+0x145/0x1c0 kernel/task_work.c:113 get_signal+0x2078/0x2500 kernel/signal.c:2523 do_signal+0x87/0x1700 arch/x86/kernel/signal.c:815 exit_to_usermode_loop+0x286/0x380 arch/x86/entry/common.c:159 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline] syscall_return_slowpath arch/x86/entry/common.c:274 [inline] do_syscall_64+0x5a9/0x6a0 arch/x86/entry/common.c:299 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x459829 Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fe68c1f4c78 EFLAGS: 0246 ORIG_RAX: 010f RAX: 0003 RBX: 0005 RCX: 00459829 RDX: 20003440 RSI: 0005 RDI: 200033c0 RBP: 0075c070 R08: 0008 R09: R10: 20003480 R11: 0246 R12: 7fe68c1f56d4 R13: 004c6706 R14: 004db7b8 R15: Modules linked in: CR2: 0010 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
BUG: unable to handle kernel NULL pointer dereference in corrupted (4)
Hello, syzbot found the following crash on: HEAD commit:4b972a01 Linux 5.2-rc6 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=17852b6ea0 kernel config: https://syzkaller.appspot.com/x/.config?x=e7c31a94f66cc0aa dashboard link: https://syzkaller.appspot.com/bug?extid=4b5d77fdf765668f9eba compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15252769a0 The bug was bisected to: commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650 Author: John Fastabend Date: Sat Jun 30 13:17:47 2018 + bpf: sockhash fix omitted bucket lock in sock_close bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=146ae35ea0 final crash:https://syzkaller.appspot.com/x/report.txt?x=166ae35ea0 console output: https://syzkaller.appspot.com/x/log.txt?x=126ae35ea0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+4b5d77fdf765668f9...@syzkaller.appspotmail.com Fixes: e9db4ef6bf4c ("bpf: sockhash fix omitted bucket lock in sock_close") BUG: kernel NULL pointer dereference, address: 00fc --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. For information about bisection process see: https://goo.gl/tpsmEJ#bisection syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
[PATCH 2/2] vimc: fix BUG: unable to handle kernel NULL pointer dereference
If vimc module is removed while streaming is active, vimc_exit runs into NULL pointer dereference error when streaming thread tries to access and lock graph_mutex in the struct media_device. media_device is embedded in struct vimc_device and when vimc is removed vimc_device and the embedded media_device goes with it, while the active stream and vimc_capture continue to access it. Fix the media_device lifetime problem by changing vimc to create shared media_device using Media Device Allocator API and vimc_capture getting a reference to vimc module. With this change, vimc module can be removed only when the references are gone. vimc can be removed after vimc_capture is removed. The following panic is fixed with this change. kernel: [ 1844.098372] Call Trace: kernel: [ 1844.098376] lock_acquire+0xb4/0x160 kernel: [ 1844.098379] ? media_pipeline_stop+0x23/0x40 kernel: [ 1844.098381] ? media_pipeline_stop+0x23/0x40 kernel: [ 1844.098385] __mutex_lock+0x8b/0x950 kernel: [ 1844.098386] ? media_pipeline_stop+0x23/0x40 kernel: [ 1844.098389] ? wait_for_completion+0xac/0x150 kernel: [ 1844.098391] ? wait_for_completion+0x12a/0x150 kernel: [ 1844.098395] ? wake_up_q+0x80/0x80 kernel: [ 1844.098397] mutex_lock_nested+0x1b/0x20 kernel: [ 1844.098398] ? mutex_lock_nested+0x1b/0x20 kernel: [ 1844.098400] media_pipeline_stop+0x23/0x40 kernel: [ 1844.098404] vimc_cap_stop_streaming+0x28/0x40 [vimc_capture] kernel: [ 1844.098406] __vb2_queue_cancel+0x30/0x2a0 kernel: [ 1844.098408] vb2_core_queue_release+0x23/0x50 kernel: [ 1844.098410] vb2_queue_release+0xe/0x10 kernel: [ 1844.098412] vimc_cap_comp_unbind+0x1d/0x40 [vimc_capture] kernel: [ 1844.098414] component_unbind.isra.8+0x27/0x40 kernel: [ 1844.098416] component_unbind_all+0xaa/0xc0 kernel: [ 1844.098418] vimc_comp_unbind+0x2d/0x60 [vimc] kernel: [ 1844.098420] take_down_master+0x24/0x40 kernel: [ 1844.098422] component_master_del+0x5e/0x80 kernel: [ 1844.098424] vimc_remove+0x27/0x90 [vimc] kernel: [ 1844.098426] platform_drv_remove+0x28/0x50 kernel: [ 1844.098428] device_release_driver_internal+0xec/0x1c0 kernel: [ 1844.098429] driver_detach+0x49/0x90 kernel: [ 1844.098432] bus_remove_driver+0x5c/0xd0 kernel: [ 1844.098433] driver_unregister+0x2c/0x40 kernel: [ 1844.098435] platform_driver_unregister+0x12/0x20 kernel: [ 1844.098437] vimc_exit+0x10/0x9fa [vimc] kernel: [ 1844.098439] __x64_sys_delete_module+0x148/0x280 kernel: [ 1844.098443] do_syscall_64+0x5a/0x120 kernel: [ 1844.098446] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Shuah Khan --- drivers/media/platform/vimc/vimc-capture.c | 17 +- drivers/media/platform/vimc/vimc-core.c| 60 -- 2 files changed, 50 insertions(+), 27 deletions(-) diff --git a/drivers/media/platform/vimc/vimc-capture.c b/drivers/media/platform/vimc/vimc-capture.c index e7d0fc2228a6..2e5cf794f60f 100644 --- a/drivers/media/platform/vimc/vimc-capture.c +++ b/drivers/media/platform/vimc/vimc-capture.c @@ -22,6 +22,7 @@ #include #include #include +#include #include "vimc-common.h" #include "vimc-streamer.h" @@ -72,6 +73,8 @@ struct vimc_cap_device { struct mutex lock; u32 sequence; struct vimc_stream stream; + /* Used for holding reference to media dev allocated by vimc-core */ + struct media_device *mdev; }; static const struct v4l2_pix_format fmt_default = { @@ -371,6 +374,7 @@ static void vimc_cap_release(struct video_device *vdev) container_of(vdev, struct vimc_cap_device, vdev); vimc_pads_cleanup(vcap->ved.pads); + media_device_delete(vcap->mdev, VIMC_CAP_DRV_NAME, THIS_MODULE); kfree(vcap); } @@ -440,12 +444,21 @@ static int vimc_cap_comp_bind(struct device *comp, struct device *master, if (!vcap) return -ENOMEM; + /* first get reference to media device allocated by vimc */ + vcap->mdev = media_device_allocate(master, NULL, NULL, + VIMC_CAP_DRV_NAME, + THIS_MODULE); + if (!vcap->mdev) { + ret = PTR_ERR(vcap->mdev); + goto err_free_vcap; + } + /* Allocate the pads */ vcap->ved.pads = vimc_pads_init(1, (const unsigned long[1]) {MEDIA_PAD_FL_SINK}); if (IS_ERR(vcap->ved.pads)) { ret = PTR_ERR(vcap->ved.pads); - goto err_free_vcap; + goto err_mdev_rls_ref; } /* Initialize the media entity */ @@ -524,6 +537,8 @@ static int vimc_cap_comp_bind(struct device *comp, struct device *master, media_entity_cleanup(&vcap->vdev.entity); err_clean_pads: vimc_pads_cleanup(vcap->ved.pads); +err_mdev_rls_ref: + media_device_delete(vcap->mdev, VIMC_CAP_DRV_NAME, THIS_MODULE); err_free_vcap: kfree(vcap); diff --git a/drivers/media/platform/vimc/vimc-core.c b
Re: shmem_recalc_inode: unable to handle kernel NULL pointer dereference
On Mon, 8 Apr 2019, Konstantin Khlebnikov wrote: > > I suppose your solution will wait for wakeup from shmem_evict_inode()? No, it's the other way round: shmem_unuse() gets on with its work without delay, shmem_evict_inode() waits until the stop_eviction count has gone down to zero, saying nobody else is at work on the inode. Waiting in shmem_evict_inode() might be more worrying, if it weren't already packed full with lock_page()s. And less attractive with the old quadratic style of swapoff, when shmem_evict_inode() would have freed the inode's swap much more efficiently than swapoff could then manage. Hugh
Re: shmem_recalc_inode: unable to handle kernel NULL pointer dereference
On 08.04.2019 9:05, Hugh Dickins wrote: On Fri, 5 Apr 2019, Konstantin Khlebnikov wrote: On 05.04.2019 5:12, Hugh Dickins wrote: Hi Alex, could you please give the patch below a try? It fixes a problem, but I'm not sure that it's your problem - please let us know. I've not yet written up the commit description, and this should end up as 4/4 in a series fixing several new swapoff issues: I'll wait to post the finished series until heard back from you. I did first try following the suggestion Konstantin had made back then, for a similar shmem_writepage() case: atomic_inc_not_zero(&sb->s_active). But it turned out to be difficult to get right in shmem_unuse(), because of the way that relies on the inode as a cursor in the list - problem when you've acquired an s_active reference, but fail to acquire inode reference, and cannot safely release the s_active reference while still holding the swaplist mutex. If VFS offered an isgrab(inode), like igrab() but acquiring s_active reference while holding i_lock, that would drop very easily into the current shmem_unuse() as a replacement there for igrab(). But the rest of the world has managed without that for years, so I'm disinclined to add it just for this. And the patch below seems good enough without it. Thanks, Hugh --- include/linux/shmem_fs.h |1 + mm/shmem.c | 39 ++- 2 files changed, 19 insertions(+), 21 deletions(-) --- 5.1-rc3/include/linux/shmem_fs.h2019-03-17 16:18:15.181820820 -0700 +++ linux/include/linux/shmem_fs.h 2019-04-04 16:18:08.193512968 -0700 @@ -21,6 +21,7 @@ struct shmem_inode_info { struct list_headswaplist; /* chain of maybes on swap */ struct shared_policypolicy; /* NUMA memory alloc policy */ struct simple_xattrsxattrs; /* list of xattrs */ + atomic_tstop_eviction; /* hold when working on inode */ struct inodevfs_inode; }; --- 5.1-rc3/mm/shmem.c 2019-03-17 16:18:15.701823872 -0700 +++ linux/mm/shmem.c2019-04-04 16:18:08.193512968 -0700 @@ -1081,9 +1081,15 @@ static void shmem_evict_inode(struct ino } spin_unlock(&sbinfo->shrinklist_lock); } - if (!list_empty(&info->swaplist)) { + while (!list_empty(&info->swaplist)) { + /* Wait while shmem_unuse() is scanning this inode... */ + wait_var_event(&info->stop_eviction, + !atomic_read(&info->stop_eviction)); mutex_lock(&shmem_swaplist_mutex); list_del_init(&info->swaplist); + /* ...but beware of the race if we peeked too early */ + if (!atomic_read(&info->stop_eviction)) + list_del_init(&info->swaplist); mutex_unlock(&shmem_swaplist_mutex); } } @@ -1227,36 +1233,27 @@ int shmem_unuse(unsigned int type, bool unsigned long *fs_pages_to_unuse) { struct shmem_inode_info *info, *next; - struct inode *inode; - struct inode *prev_inode = NULL; int error = 0; if (list_empty(&shmem_swaplist)) return 0; mutex_lock(&shmem_swaplist_mutex); - - /* -* The extra refcount on the inode is necessary to safely dereference -* p->next after re-acquiring the lock. New shmem inodes with swap -* get added to the end of the list and we will scan them all. -*/ list_for_each_entry_safe(info, next, &shmem_swaplist, swaplist) { if (!info->swapped) { list_del_init(&info->swaplist); continue; } - - inode = igrab(&info->vfs_inode); - if (!inode) - continue; - + /* +* Drop the swaplist mutex while searching the inode for swap; +* but before doing so, make sure shmem_evict_inode() will not +* remove placeholder inode from swaplist, nor let it be freed +* (igrab() would protect from unlink, but not from unmount). +*/ + atomic_inc(&info->stop_eviction); mutex_unlock(&shmem_swaplist_mutex); - if (prev_inode) - iput(prev_inode); - prev_inode = inode; This seems too ad hoc solution. I see what you mean by "ad hoc", but disagree with "too" ad hoc: it's an appropriate solution, and a general one - I didn't invent it for this, but for the huge tmpfs recoveries work items four years ago; just changed the name from "info->recoveries" to "info->stop_eviction" to let it be generalized to this swapoff case. I prefer mine, since it simplifies shmem_unuse() (no igrab!), and has the
Re: shmem_recalc_inode: unable to handle kernel NULL pointer dereference
On Fri, 5 Apr 2019, Konstantin Khlebnikov wrote: > On 05.04.2019 5:12, Hugh Dickins wrote: > > Hi Alex, could you please give the patch below a try? It fixes a > > problem, but I'm not sure that it's your problem - please let us know. > > > > I've not yet written up the commit description, and this should end up > > as 4/4 in a series fixing several new swapoff issues: I'll wait to post > > the finished series until heard back from you. > > > > I did first try following the suggestion Konstantin had made back then, > > for a similar shmem_writepage() case: atomic_inc_not_zero(&sb->s_active). > > > > But it turned out to be difficult to get right in shmem_unuse(), because > > of the way that relies on the inode as a cursor in the list - problem > > when you've acquired an s_active reference, but fail to acquire inode > > reference, and cannot safely release the s_active reference while still > > holding the swaplist mutex. > > > > If VFS offered an isgrab(inode), like igrab() but acquiring s_active > > reference while holding i_lock, that would drop very easily into the > > current shmem_unuse() as a replacement there for igrab(). But the rest > > of the world has managed without that for years, so I'm disinclined to > > add it just for this. And the patch below seems good enough without it. > > > > Thanks, > > Hugh > > > > --- > > > > include/linux/shmem_fs.h |1 + > > mm/shmem.c | 39 ++- > > 2 files changed, 19 insertions(+), 21 deletions(-) > > > > --- 5.1-rc3/include/linux/shmem_fs.h2019-03-17 16:18:15.181820820 > > -0700 > > +++ linux/include/linux/shmem_fs.h 2019-04-04 16:18:08.193512968 -0700 > > @@ -21,6 +21,7 @@ struct shmem_inode_info { > > struct list_headswaplist; /* chain of maybes on swap */ > > struct shared_policypolicy; /* NUMA memory alloc policy > > */ > > struct simple_xattrsxattrs; /* list of xattrs */ > > + atomic_tstop_eviction; /* hold when working on inode > > */ > > struct inodevfs_inode; > > }; > > --- 5.1-rc3/mm/shmem.c2019-03-17 16:18:15.701823872 -0700 > > +++ linux/mm/shmem.c2019-04-04 16:18:08.193512968 -0700 > > @@ -1081,9 +1081,15 @@ static void shmem_evict_inode(struct ino > > } > > spin_unlock(&sbinfo->shrinklist_lock); > > } > > - if (!list_empty(&info->swaplist)) { > > + while (!list_empty(&info->swaplist)) { > > + /* Wait while shmem_unuse() is scanning this inode... > > */ > > + wait_var_event(&info->stop_eviction, > > + !atomic_read(&info->stop_eviction)); > > mutex_lock(&shmem_swaplist_mutex); > > list_del_init(&info->swaplist); > > + /* ...but beware of the race if we peeked too early > > */ > > + if (!atomic_read(&info->stop_eviction)) > > + list_del_init(&info->swaplist); > > mutex_unlock(&shmem_swaplist_mutex); > > } > > } > > @@ -1227,36 +1233,27 @@ int shmem_unuse(unsigned int type, bool > > unsigned long *fs_pages_to_unuse) > > { > > struct shmem_inode_info *info, *next; > > - struct inode *inode; > > - struct inode *prev_inode = NULL; > > int error = 0; > > if (list_empty(&shmem_swaplist)) > > return 0; > > mutex_lock(&shmem_swaplist_mutex); > > - > > - /* > > -* The extra refcount on the inode is necessary to safely dereference > > -* p->next after re-acquiring the lock. New shmem inodes with swap > > -* get added to the end of the list and we will scan them all. > > -*/ > > list_for_each_entry_safe(info, next, &shmem_swaplist, swaplist) { > > if (!info->swapped) { > > list_del_init(&info->swaplist); > > continue; > > } > > - > > - inode = igrab(&info->vfs_inode); > > - if (!inode) > > - continue; > > - > > + /* > > +* Drop the swaplist mutex while searching the inode for > > swap; > > +* but before doing so, make sure shmem_evict_inode() will > > not > > +* remove placeholder inode from swaplist, nor let it be > > freed > > +* (igrab() would protect from unlink, but not from unmount). > > +*/ > > + atomic_inc(&info->stop_eviction); > > mutex_unlock(&shmem_swaplist_mutex); > > - if (prev_inode) > > - iput(prev_inode); > > - prev_inode = inode; > This seems too ad hoc solution. I see what you mean by "ad hoc", but disagree with "too" ad hoc: it's an appropriate solution, and a general one - I didn't invent it for this, but for the huge tmpfs recoveries work items four years ago; just changed the n
Re: shmem_recalc_inode: unable to handle kernel NULL pointer dereference
On 05.04.2019 5:12, Hugh Dickins wrote: On Tue, 2 Apr 2019, Hugh Dickins wrote: On Sun, 31 Mar 2019, Hugh Dickins wrote: On Sun, 31 Mar 2019, Alex Xu (Hello71) wrote: Excerpts from Vineeth Pillai's message of March 25, 2019 6:08 pm: On Sun, Mar 24, 2019 at 11:30 AM Alex Xu (Hello71) wrote: I get this BUG in 5.1-rc1 sometimes when powering off the machine. I suspect my setup erroneously executes two swapoff+cryptsetup close operations simultaneously, so a race condition is triggered. I am using a single swap on a plain dm-crypt device on a MBR partition on a SATA drive. I think the problem is probably related to b56a2d8af9147a4efe4011b60d93779c0461ca97, so CCing the related people. Could you please provide more information on this - stack trace, dmesg etc? Is it easily reproducible? If yes, please detail the steps so that I can try it inhouse. Thanks, Vineeth Some info from the BUG entry (I didn't bother to type it all, low-quality image available upon request): BUG: unable to handle kernel NULL pointer dereference at #PF error: [normal kernel read fault] PGD 0 P4D 0 Oops: [#1] SMP CPU: 0 Comm: swapoff Not tainted 5.1.0-rc1+ #2 RIP: 0010:shmem_recalc_inode+0x41/0x90 Call Trace: ? shmem_undo_range ? rb_erase_cached ? set_next_entity ? __inode_wait_for_writeback ? shmem_truncate_range ? shmem_evict_inode ? evict ? shmem_unuse ? try_to_unuse ? swapcache_free_entries ? _cond_resched ? __se_sys_swapoff ? do_syscall_64 ? entry_SYSCALL_64_after_hwframe As I said, it only occurs occasionally on shutdown. I think it is a safe guess that it can only occur when the swap is not empty, but possibly other conditions are necessary, so I will test further. Thanks for the update, Alex. I'm looking into a couple of bugs with the 5.1-rc swapoff, but this one doesn't look like anything I know so far. shmem_recalc_inode() is a surprising place to crash: it's as if the igrab() in shmem_unuse() were not working. Yes, please do send Vineeth and me (or the lists) your low-quality image, in case we can extract any more info from it; and also please the disassembly of your kernel's shmem_recalc_inode(), so we can be sure of exactly what it's crashing on (though I expect that will leave me as puzzled as before). If you want to experiment with one of my fixes, not yet written up and posted, just try changing SWAP_UNUSE_MAX_TRIES in mm/swapfile.c from 3 to INT_MAX: I don't see how that issue could manifest as crashing in shmem_recalc_inode(), but I may just be too stupid to see it. Thanks for the image and disassembly you sent: which showed that the 81117351: 48 83 3f 00 cmpq $0x0,(%rdi) you are crashing on, is the "if (sbinfo->max_blocks)" in the inlined shmem_inode_unacct_blocks(): inode->i_sb->s_fs_info is NULL, which is something that shmem_put_super() does. Eight-year-old memories stirred: I knew when looking at Vineeth's patch, that I ought to look back through the history of mm/shmem.c, to check some points that Konstantin Khlebnikov had made years ago, that surprised me then and were in danger of surprising us again with this rework. But I failed to do so: thank you Alex, for reporting this bug and pointing us back there. igrab() protects from eviction but does not protect from unmounting. I bet that is what you are hitting, though I've not even read through 2.6.39's 778dd893ae785 ("tmpfs: fix race between umount and swapoff") again yet, and not begun to think of the fix for it this time around; but wanted to let you know that this bug is now (probably) identified. Hi Alex, could you please give the patch below a try? It fixes a problem, but I'm not sure that it's your problem - please let us know. I've not yet written up the commit description, and this should end up as 4/4 in a series fixing several new swapoff issues: I'll wait to post the finished series until heard back from you. I did first try following the suggestion Konstantin had made back then, for a similar shmem_writepage() case: atomic_inc_not_zero(&sb->s_active). But it turned out to be difficult to get right in shmem_unuse(), because of the way that relies on the inode as a cursor in the list - problem when you've acquired an s_active reference, but fail to acquire inode reference, and cannot safely release the s_active reference while still holding the swaplist mutex. If VFS offered an isgrab(inode), like igrab() but acquiring s_active reference while holding i_lock, that would drop very easily into the current shmem_unuse() as a replacement there for igrab(). But the rest of the world has managed without that for years, so I'm disinclined to add it just for this. And the patch below seems good enough without it. Thanks, Hugh --- include/linux/shmem_fs.h |1 + mm/shmem.c | 39 ++- 2 files changed,
Re: shmem_recalc_inode: unable to handle kernel NULL pointer dereference
On Tue, 2 Apr 2019, Hugh Dickins wrote: > On Sun, 31 Mar 2019, Hugh Dickins wrote: > > On Sun, 31 Mar 2019, Alex Xu (Hello71) wrote: > > > Excerpts from Vineeth Pillai's message of March 25, 2019 6:08 pm: > > > > On Sun, Mar 24, 2019 at 11:30 AM Alex Xu (Hello71) > > > > wrote: > > > >> > > > >> I get this BUG in 5.1-rc1 sometimes when powering off the machine. I > > > >> suspect my setup erroneously executes two swapoff+cryptsetup close > > > >> operations simultaneously, so a race condition is triggered. > > > >> > > > >> I am using a single swap on a plain dm-crypt device on a MBR partition > > > >> on a SATA drive. > > > >> > > > >> I think the problem is probably related to > > > >> b56a2d8af9147a4efe4011b60d93779c0461ca97, so CCing the related people. > > > >> > > > > Could you please provide more information on this - stack trace, dmesg > > > > etc? > > > > Is it easily reproducible? If yes, please detail the steps so that I > > > > can try it inhouse. > > > > > > > > Thanks, > > > > Vineeth > > > > > > > > > > Some info from the BUG entry (I didn't bother to type it all, > > > low-quality image available upon request): > > > > > > BUG: unable to handle kernel NULL pointer dereference at > > > #PF error: [normal kernel read fault] > > > PGD 0 P4D 0 > > > Oops: [#1] SMP > > > CPU: 0 Comm: swapoff Not tainted 5.1.0-rc1+ #2 > > > RIP: 0010:shmem_recalc_inode+0x41/0x90 > > > > > > Call Trace: > > > ? shmem_undo_range > > > ? rb_erase_cached > > > ? set_next_entity > > > ? __inode_wait_for_writeback > > > ? shmem_truncate_range > > > ? shmem_evict_inode > > > ? evict > > > ? shmem_unuse > > > ? try_to_unuse > > > ? swapcache_free_entries > > > ? _cond_resched > > > ? __se_sys_swapoff > > > ? do_syscall_64 > > > ? entry_SYSCALL_64_after_hwframe > > > > > > As I said, it only occurs occasionally on shutdown. I think it is a safe > > > guess that it can only occur when the swap is not empty, but possibly > > > other conditions are necessary, so I will test further. > > > > Thanks for the update, Alex. I'm looking into a couple of bugs with the > > 5.1-rc swapoff, but this one doesn't look like anything I know so far. > > shmem_recalc_inode() is a surprising place to crash: it's as if the > > igrab() in shmem_unuse() were not working. > > > > Yes, please do send Vineeth and me (or the lists) your low-quality image, > > in case we can extract any more info from it; and also please the > > disassembly of your kernel's shmem_recalc_inode(), so we can be sure of > > exactly what it's crashing on (though I expect that will leave me as > > puzzled as before). > > > > If you want to experiment with one of my fixes, not yet written up and > > posted, just try changing SWAP_UNUSE_MAX_TRIES in mm/swapfile.c from > > 3 to INT_MAX: I don't see how that issue could manifest as crashing in > > shmem_recalc_inode(), but I may just be too stupid to see it. > > Thanks for the image and disassembly you sent: which showed that the > 81117351: 48 83 3f 00 cmpq $0x0,(%rdi) > you are crashing on, is the "if (sbinfo->max_blocks)" in the inlined > shmem_inode_unacct_blocks(): inode->i_sb->s_fs_info is NULL, which is > something that shmem_put_super() does. > > Eight-year-old memories stirred: I knew when looking at Vineeth's patch, > that I ought to look back through the history of mm/shmem.c, to check > some points that Konstantin Khlebnikov had made years ago, that > surprised me then and were in danger of surprising us again with this > rework. But I failed to do so: thank you Alex, for reporting this bug > and pointing us back there. > > igrab() protects from eviction but does not protect from unmounting. > I bet that is what you are hitting, though I've not even read through > 2.6.39's 778dd893ae785 ("tmpfs: fix race between umount and swapoff") > again yet, and not begun to think of the fix for it this time around; > but wanted to let you know that this bug is now (probably) identified. Hi Alex, could you please give the patch below a try? It fixes a problem, but I'm not sure that it's your problem - please let us know. I've not yet written up th
Re: shmem_recalc_inode: unable to handle kernel NULL pointer dereference
On Sun, 31 Mar 2019, Hugh Dickins wrote: > On Sun, 31 Mar 2019, Alex Xu (Hello71) wrote: > > Excerpts from Vineeth Pillai's message of March 25, 2019 6:08 pm: > > > On Sun, Mar 24, 2019 at 11:30 AM Alex Xu (Hello71) > > > wrote: > > >> > > >> I get this BUG in 5.1-rc1 sometimes when powering off the machine. I > > >> suspect my setup erroneously executes two swapoff+cryptsetup close > > >> operations simultaneously, so a race condition is triggered. > > >> > > >> I am using a single swap on a plain dm-crypt device on a MBR partition > > >> on a SATA drive. > > >> > > >> I think the problem is probably related to > > >> b56a2d8af9147a4efe4011b60d93779c0461ca97, so CCing the related people. > > >> > > > Could you please provide more information on this - stack trace, dmesg > > > etc? > > > Is it easily reproducible? If yes, please detail the steps so that I > > > can try it inhouse. > > > > > > Thanks, > > > Vineeth > > > > > > > Some info from the BUG entry (I didn't bother to type it all, > > low-quality image available upon request): > > > > BUG: unable to handle kernel NULL pointer dereference at > > #PF error: [normal kernel read fault] > > PGD 0 P4D 0 > > Oops: [#1] SMP > > CPU: 0 Comm: swapoff Not tainted 5.1.0-rc1+ #2 > > RIP: 0010:shmem_recalc_inode+0x41/0x90 > > > > Call Trace: > > ? shmem_undo_range > > ? rb_erase_cached > > ? set_next_entity > > ? __inode_wait_for_writeback > > ? shmem_truncate_range > > ? shmem_evict_inode > > ? evict > > ? shmem_unuse > > ? try_to_unuse > > ? swapcache_free_entries > > ? _cond_resched > > ? __se_sys_swapoff > > ? do_syscall_64 > > ? entry_SYSCALL_64_after_hwframe > > > > As I said, it only occurs occasionally on shutdown. I think it is a safe > > guess that it can only occur when the swap is not empty, but possibly > > other conditions are necessary, so I will test further. > > Thanks for the update, Alex. I'm looking into a couple of bugs with the > 5.1-rc swapoff, but this one doesn't look like anything I know so far. > shmem_recalc_inode() is a surprising place to crash: it's as if the > igrab() in shmem_unuse() were not working. > > Yes, please do send Vineeth and me (or the lists) your low-quality image, > in case we can extract any more info from it; and also please the > disassembly of your kernel's shmem_recalc_inode(), so we can be sure of > exactly what it's crashing on (though I expect that will leave me as > puzzled as before). > > If you want to experiment with one of my fixes, not yet written up and > posted, just try changing SWAP_UNUSE_MAX_TRIES in mm/swapfile.c from > 3 to INT_MAX: I don't see how that issue could manifest as crashing in > shmem_recalc_inode(), but I may just be too stupid to see it. Thanks for the image and disassembly you sent: which showed that the 81117351: 48 83 3f 00 cmpq $0x0,(%rdi) you are crashing on, is the "if (sbinfo->max_blocks)" in the inlined shmem_inode_unacct_blocks(): inode->i_sb->s_fs_info is NULL, which is something that shmem_put_super() does. Eight-year-old memories stirred: I knew when looking at Vineeth's patch, that I ought to look back through the history of mm/shmem.c, to check some points that Konstantin Khlebnikov had made years ago, that surprised me then and were in danger of surprising us again with this rework. But I failed to do so: thank you Alex, for reporting this bug and pointing us back there. igrab() protects from eviction but does not protect from unmounting. I bet that is what you are hitting, though I've not even read through 2.6.39's 778dd893ae785 ("tmpfs: fix race between umount and swapoff") again yet, and not begun to think of the fix for it this time around; but wanted to let you know that this bug is now (probably) identified. Hugh
Re: shmem_recalc_inode: unable to handle kernel NULL pointer dereference
On Sun, 31 Mar 2019, Alex Xu (Hello71) wrote: > Excerpts from Vineeth Pillai's message of March 25, 2019 6:08 pm: > > On Sun, Mar 24, 2019 at 11:30 AM Alex Xu (Hello71) > > wrote: > >> > >> I get this BUG in 5.1-rc1 sometimes when powering off the machine. I > >> suspect my setup erroneously executes two swapoff+cryptsetup close > >> operations simultaneously, so a race condition is triggered. > >> > >> I am using a single swap on a plain dm-crypt device on a MBR partition > >> on a SATA drive. > >> > >> I think the problem is probably related to > >> b56a2d8af9147a4efe4011b60d93779c0461ca97, so CCing the related people. > >> > > Could you please provide more information on this - stack trace, dmesg etc? > > Is it easily reproducible? If yes, please detail the steps so that I > > can try it inhouse. > > > > Thanks, > > Vineeth > > > > Some info from the BUG entry (I didn't bother to type it all, > low-quality image available upon request): > > BUG: unable to handle kernel NULL pointer dereference at > #PF error: [normal kernel read fault] > PGD 0 P4D 0 > Oops: [#1] SMP > CPU: 0 Comm: swapoff Not tainted 5.1.0-rc1+ #2 > RIP: 0010:shmem_recalc_inode+0x41/0x90 > > Call Trace: > ? shmem_undo_range > ? rb_erase_cached > ? set_next_entity > ? __inode_wait_for_writeback > ? shmem_truncate_range > ? shmem_evict_inode > ? evict > ? shmem_unuse > ? try_to_unuse > ? swapcache_free_entries > ? _cond_resched > ? __se_sys_swapoff > ? do_syscall_64 > ? entry_SYSCALL_64_after_hwframe > > As I said, it only occurs occasionally on shutdown. I think it is a safe > guess that it can only occur when the swap is not empty, but possibly > other conditions are necessary, so I will test further. Thanks for the update, Alex. I'm looking into a couple of bugs with the 5.1-rc swapoff, but this one doesn't look like anything I know so far. shmem_recalc_inode() is a surprising place to crash: it's as if the igrab() in shmem_unuse() were not working. Yes, please do send Vineeth and me (or the lists) your low-quality image, in case we can extract any more info from it; and also please the disassembly of your kernel's shmem_recalc_inode(), so we can be sure of exactly what it's crashing on (though I expect that will leave me as puzzled as before). If you want to experiment with one of my fixes, not yet written up and posted, just try changing SWAP_UNUSE_MAX_TRIES in mm/swapfile.c from 3 to INT_MAX: I don't see how that issue could manifest as crashing in shmem_recalc_inode(), but I may just be too stupid to see it. Thanks, Hugh
Re: shmem_recalc_inode: unable to handle kernel NULL pointer dereference
Excerpts from Vineeth Pillai's message of March 25, 2019 6:08 pm: > On Sun, Mar 24, 2019 at 11:30 AM Alex Xu (Hello71) wrote: >> >> I get this BUG in 5.1-rc1 sometimes when powering off the machine. I >> suspect my setup erroneously executes two swapoff+cryptsetup close >> operations simultaneously, so a race condition is triggered. >> >> I am using a single swap on a plain dm-crypt device on a MBR partition >> on a SATA drive. >> >> I think the problem is probably related to >> b56a2d8af9147a4efe4011b60d93779c0461ca97, so CCing the related people. >> > Could you please provide more information on this - stack trace, dmesg etc? > Is it easily reproducible? If yes, please detail the steps so that I > can try it inhouse. > > Thanks, > Vineeth > Some info from the BUG entry (I didn't bother to type it all, low-quality image available upon request): BUG: unable to handle kernel NULL pointer dereference at #PF error: [normal kernel read fault] PGD 0 P4D 0 Oops: [#1] SMP CPU: 0 Comm: swapoff Not tainted 5.1.0-rc1+ #2 RIP: 0010:shmem_recalc_inode+0x41/0x90 Call Trace: ? shmem_undo_range ? rb_erase_cached ? set_next_entity ? __inode_wait_for_writeback ? shmem_truncate_range ? shmem_evict_inode ? evict ? shmem_unuse ? try_to_unuse ? swapcache_free_entries ? _cond_resched ? __se_sys_swapoff ? do_syscall_64 ? entry_SYSCALL_64_after_hwframe As I said, it only occurs occasionally on shutdown. I think it is a safe guess that it can only occur when the swap is not empty, but possibly other conditions are necessary, so I will test further.
Re: shmem_recalc_inode: unable to handle kernel NULL pointer dereference
On Sun, Mar 24, 2019 at 11:30 AM Alex Xu (Hello71) wrote: > > I get this BUG in 5.1-rc1 sometimes when powering off the machine. I > suspect my setup erroneously executes two swapoff+cryptsetup close > operations simultaneously, so a race condition is triggered. > > I am using a single swap on a plain dm-crypt device on a MBR partition > on a SATA drive. > > I think the problem is probably related to > b56a2d8af9147a4efe4011b60d93779c0461ca97, so CCing the related people. > Could you please provide more information on this - stack trace, dmesg etc? Is it easily reproducible? If yes, please detail the steps so that I can try it inhouse. Thanks, Vineeth
shmem_recalc_inode: unable to handle kernel NULL pointer dereference
I get this BUG in 5.1-rc1 sometimes when powering off the machine. I suspect my setup erroneously executes two swapoff+cryptsetup close operations simultaneously, so a race condition is triggered. I am using a single swap on a plain dm-crypt device on a MBR partition on a SATA drive. I think the problem is probably related to b56a2d8af9147a4efe4011b60d93779c0461ca97, so CCing the related people. Thanks, Alex.
Re: BUG: unable to handle kernel NULL pointer dereference in hci_uart_set_flow_control
syzbot has bisected this bug to: commit 162f812f23bab583f5d514ca0e4df67797ac9cdf Author: Loic Poulain Date: Mon Sep 19 14:29:27 2016 + Bluetooth: hci_uart: Add Marvell support bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=112f0a3b20 start commit: 162f812f Bluetooth: hci_uart: Add Marvell support git tree: upstream final crash:https://syzkaller.appspot.com/x/report.txt?x=132f0a3b20 console output: https://syzkaller.appspot.com/x/log.txt?x=152f0a3b20 kernel config: https://syzkaller.appspot.com/x/.config?x=9a31fb246de2a622 dashboard link: https://syzkaller.appspot.com/bug?extid=79337b501d6aa974d0f6 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15397fd720 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=151e9e6d20 Reported-by: syzbot+79337b501d6aa974d...@syzkaller.appspotmail.com Fixes: 162f812f23ba ("Bluetooth: hci_uart: Add Marvell support") For information about bisection process see: https://goo.gl/tpsmEJ#bisection
BUG: unable to handle kernel NULL pointer dereference in hci_uart_set_flow_control
Hello, syzbot found the following crash on: HEAD commit:54c49016 Merge tag 'arc-5.1-rc2' of git://git.kernel.org/p.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=150552df20 kernel config: https://syzkaller.appspot.com/x/.config?x=9a31fb246de2a622 dashboard link: https://syzkaller.appspot.com/bug?extid=79337b501d6aa974d0f6 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15397fd720 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=151e9e6d20 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+79337b501d6aa974d...@syzkaller.appspotmail.com BUG: unable to handle kernel NULL pointer dereference at #PF error: [INSTR] PGD a7d75067 P4D a7d75067 PUD 9fa83067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 1 PID: 1173 Comm: kworker/u5:0 Not tainted 5.1.0-rc1+ #31 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: hci0 hci_power_on RIP: 0010: (null) Code: Bad RIP value. RSP: 0018:8880a7807a28 EFLAGS: 00010246 RAX: RBX: 87ac4d20 RCX: RDX: 10f589bd RSI: 111014fff58f RDI: 8880a0f6ca00 RBP: 8880a7807b00 R08: 8880a7ffa380 R09: 0004 R10: ed10141ed945 R11: 8880a0f6ca2f R12: 8880a0f6ca00 R13: 111014f00f47 R14: 8880a0f6ca10 R15: FS: () GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 9fa85000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: hci_uart_set_flow_control+0x41e/0x600 drivers/bluetooth/hci_ldisc.c:327 mrvl_setup+0x22/0x110 drivers/bluetooth/hci_mrvl.c:348 hci_uart_setup+0x1c4/0x490 drivers/bluetooth/hci_ldisc.c:418 hci_dev_do_open+0x78c/0x1780 net/bluetooth/hci_core.c:1450 hci_power_on+0x10d/0x580 net/bluetooth/hci_core.c:2173 process_one_work+0x98e/0x1790 kernel/workqueue.c:2269 worker_thread+0x98/0xe40 kernel/workqueue.c:2415 kthread+0x357/0x430 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Modules linked in: CR2: ---[ end trace 1fd0bc84b188ab23 ]--- RIP: 0010: (null) Code: Bad RIP value. RSP: 0018:8880a7807a28 EFLAGS: 00010246 RAX: RBX: 87ac4d20 RCX: RDX: 10f589bd RSI: 111014fff58f RDI: 8880a0f6ca00 RBP: 8880a7807b00 R08: 8880a7ffa380 R09: 0004 R10: ed10141ed945 R11: 8880a0f6ca2f R12: 8880a0f6ca00 R13: 111014f00f47 R14: 8880a0f6ca10 R15: FS: () GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 9fa85000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: BUG: unable to handle kernel NULL pointer dereference in __generic_file_write_iter
On Thu, Feb 21, 2019 at 11:36:24AM -0800, Andrew Morton wrote: > On Thu, 21 Feb 2019 06:52:04 -0800 syzbot > wrote: > > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:4aa9fc2a435a Revert "mm, memory_hotplug: initialize struct.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=1101382f40 > > kernel config: https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20 > > dashboard link: https://syzkaller.appspot.com/bug?extid=ca95b2b7aef9e7cbd6ab > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > Unfortunately, I don't have any reproducer for this crash yet. > > Not understanding. That seems to be saying that we got a NULL pointer > deref in __generic_file_write_iter() at > > written = generic_perform_write(file, from, iocb->ki_pos); > > which isn't possible. > > I'm not seeing recent changes in there which could have caused this. Help. FWIW, the panic happened in generic_perform_write() when it called a_ops->write_begin, which was NULL. I agree with Jann that the unwinders should handle this scenario better. -- Josh
Re: missing stack trace entry on NULL pointer call [was: Re: BUG: unable to handle kernel NULL pointer dereference in __generic_file_write_iter]
On Thu, Feb 28, 2019 at 5:34 PM Jann Horn wrote: > > On Thu, Feb 28, 2019 at 1:57 PM Thomas Gleixner wrote: > > On Thu, 28 Feb 2019, Jann Horn wrote: > > > +Josh for unwinding, +x86 folks > > > On Wed, Feb 27, 2019 at 11:43 PM Andrew Morton > > > wrote: > > > > On Thu, 21 Feb 2019 06:52:04 -0800 syzbot > > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > syzbot found the following crash on: > > > > > > > > > > HEAD commit:4aa9fc2a435a Revert "mm, memory_hotplug: initialize > > > > > struct.. > > > > > git tree: upstream > > > > > console output: > > > > > https://syzkaller.appspot.com/x/log.txt?x=1101382f40 > > > > > kernel config: > > > > > https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20 > > > > > dashboard link: > > > > > https://syzkaller.appspot.com/bug?extid=ca95b2b7aef9e7cbd6ab > > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > > > > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > > > > > Not understanding. That seems to be saying that we got a NULL pointer > > > > deref in __generic_file_write_iter() at > > > > > > > > written = generic_perform_write(file, from, > > > > iocb->ki_pos); > > > > > > > > which isn't possible. > > > > > > > > I'm not seeing recent changes in there which could have caused this. > > > > Help. > > > > > > + > > > > > > Maybe the problem is that the frame pointer unwinder isn't designed to > > > cope with NULL function pointers - or more generally, with an > > > unwinding operation that starts before the function's frame pointer > > > has been set up? > > > > > > Unwinding starts at show_trace_log_lvl(). That begins with > > > unwind_start(), which calls __unwind_start(), which uses > > > get_frame_pointer(), which just returns regs->bp. But that frame > > > pointer points to the part of the stack that's storing the address of > > > the caller of the function that called NULL; the caller of NULL is > > > skipped, as far as I can tell. > > > > > > What's kind of annoying here is that we don't have a proper frame set > > > up yet, we only have half a stack frame (saved RIP but no saved RBP). > > > > That wreckage is related to the fact that the indirect calls are going > > through __x86_indirect_thunk_$REG. I just verified on a VM with some other > > callback NULL'ed that the resulting backtrace is not really helpful. > > > > So in that case generic_perform_write() has two indirect calls: > > > > mapping->a_ops->write_begin() and ->write_end() > > Does the indirect thunk thing really make any difference? When you > arrive at RIP=NULL, RSP points to a saved instruction pointer, just > like when indirect calls are compiled normally. > > I just compiled kernels with artificial calls to a NULL function > pointer (in prctl_set_seccomp()), with retpoline disabled, with both > unwinders. The ORC unwinder shows a call trace with "?" everywhere > that doesn't show the caller: [...] > So I think this doesn't really have anything to do with > __x86_indirect_thunk_$REG, and the best possible fix might be to teach > the unwinders that RIP==NULL means "pretend that RIP is *real_RSP and > that RSP is real_RSP+8, and report *real_RSP as the first element of > the backtrace". Cooking up some patches now...
Re: missing stack trace entry on NULL pointer call [was: Re: BUG: unable to handle kernel NULL pointer dereference in __generic_file_write_iter]
On Thu, Feb 28, 2019 at 1:57 PM Thomas Gleixner wrote: > On Thu, 28 Feb 2019, Jann Horn wrote: > > +Josh for unwinding, +x86 folks > > On Wed, Feb 27, 2019 at 11:43 PM Andrew Morton > > wrote: > > > On Thu, 21 Feb 2019 06:52:04 -0800 syzbot > > > wrote: > > > > > > > Hello, > > > > > > > > syzbot found the following crash on: > > > > > > > > HEAD commit:4aa9fc2a435a Revert "mm, memory_hotplug: initialize > > > > struct.. > > > > git tree: upstream > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1101382f40 > > > > kernel config: > > > > https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20 > > > > dashboard link: > > > > https://syzkaller.appspot.com/bug?extid=ca95b2b7aef9e7cbd6ab > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > > > Not understanding. That seems to be saying that we got a NULL pointer > > > deref in __generic_file_write_iter() at > > > > > > written = generic_perform_write(file, from, iocb->ki_pos); > > > > > > which isn't possible. > > > > > > I'm not seeing recent changes in there which could have caused this. > > > Help. > > > > + > > > > Maybe the problem is that the frame pointer unwinder isn't designed to > > cope with NULL function pointers - or more generally, with an > > unwinding operation that starts before the function's frame pointer > > has been set up? > > > > Unwinding starts at show_trace_log_lvl(). That begins with > > unwind_start(), which calls __unwind_start(), which uses > > get_frame_pointer(), which just returns regs->bp. But that frame > > pointer points to the part of the stack that's storing the address of > > the caller of the function that called NULL; the caller of NULL is > > skipped, as far as I can tell. > > > > What's kind of annoying here is that we don't have a proper frame set > > up yet, we only have half a stack frame (saved RIP but no saved RBP). > > That wreckage is related to the fact that the indirect calls are going > through __x86_indirect_thunk_$REG. I just verified on a VM with some other > callback NULL'ed that the resulting backtrace is not really helpful. > > So in that case generic_perform_write() has two indirect calls: > > mapping->a_ops->write_begin() and ->write_end() Does the indirect thunk thing really make any difference? When you arrive at RIP=NULL, RSP points to a saved instruction pointer, just like when indirect calls are compiled normally. I just compiled kernels with artificial calls to a NULL function pointer (in prctl_set_seccomp()), with retpoline disabled, with both unwinders. The ORC unwinder shows a call trace with "?" everywhere that doesn't show the caller: [ 228.219140] BUG: unable to handle kernel NULL pointer dereference at [ 228.223897] #PF error: [INSTR] [ 228.224562] PGD 0 P4D 0 [ 228.225119] Oops: 0010 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN [ 228.226319] CPU: 1 PID: 1099 Comm: artificial_null Not tainted 5.0.0-rc8+ #299 [ 228.227818] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 228.229542] RIP: 0010: (null) [ 228.230331] Code: Bad RIP value. [ 228.231011] RSP: 0018:8881d798fe88 EFLAGS: 00010246 [ 228.232104] RAX: ffda RBX: 0016 RCX: a0368205 [ 228.233599] RDX: dc00 RSI: 7ffde0d71168 RDI: 0042 [ 228.235077] RBP: 11103af31fd4 R08: 561b50807740 R09: 0016 [ 228.236557] R10: R11: R12: 0042 [ 228.238039] R13: R14: 7ffde0d71168 R15: 561b50807740 [ 228.239517] FS: 7fe31f1cf700() GS:8881eb04() knlGS: [ 228.241213] CS: 0010 DS: ES: CR0: 80050033 [ 228.242411] CR2: ffd6 CR3: 0001df8b8004 CR4: 00360ee0 [ 228.243886] DR0: 000000000000 DR1: 0000 DR2: 0000 [ 228.245364] DR3: DR6: fffe0ff0 DR7: 0400 [ 228.246841] Call Trace: [ 228.247366] ? __x64_sys_prctl+0x402/0x680 [ 228.248224] ? __ia32_sys_prctl+0x6e0/0x6e0 [ 228.249106] ? __do_page_fault+0x457/0x620 [ 228.249969] ? do_syscall_64+0x6d/0x160 [ 228.250778] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 [...] whereas the FP unwinder shows this, listing prctl_set_seccomp only with a question mark: [
Re: missing stack trace entry on NULL pointer call [was: Re: BUG: unable to handle kernel NULL pointer dereference in __generic_file_write_iter]
On Thu, 28 Feb 2019, Jann Horn wrote: > +Josh for unwinding, +x86 folks > On Wed, Feb 27, 2019 at 11:43 PM Andrew Morton > wrote: > > On Thu, 21 Feb 2019 06:52:04 -0800 syzbot > > wrote: > > > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit:4aa9fc2a435a Revert "mm, memory_hotplug: initialize > > > struct.. > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1101382f40 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20 > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=ca95b2b7aef9e7cbd6ab > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > Not understanding. That seems to be saying that we got a NULL pointer > > deref in __generic_file_write_iter() at > > > > written = generic_perform_write(file, from, iocb->ki_pos); > > > > which isn't possible. > > > > I'm not seeing recent changes in there which could have caused this. Help. > > + > > Maybe the problem is that the frame pointer unwinder isn't designed to > cope with NULL function pointers - or more generally, with an > unwinding operation that starts before the function's frame pointer > has been set up? > > Unwinding starts at show_trace_log_lvl(). That begins with > unwind_start(), which calls __unwind_start(), which uses > get_frame_pointer(), which just returns regs->bp. But that frame > pointer points to the part of the stack that's storing the address of > the caller of the function that called NULL; the caller of NULL is > skipped, as far as I can tell. > > What's kind of annoying here is that we don't have a proper frame set > up yet, we only have half a stack frame (saved RIP but no saved RBP). That wreckage is related to the fact that the indirect calls are going through __x86_indirect_thunk_$REG. I just verified on a VM with some other callback NULL'ed that the resulting backtrace is not really helpful. So in that case generic_perform_write() has two indirect calls: mapping->a_ops->write_begin() and ->write_end() Thanks, tglx
missing stack trace entry on NULL pointer call [was: Re: BUG: unable to handle kernel NULL pointer dereference in __generic_file_write_iter]
+Josh for unwinding, +x86 folks On Wed, Feb 27, 2019 at 11:43 PM Andrew Morton wrote: > On Thu, 21 Feb 2019 06:52:04 -0800 syzbot > wrote: > > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:4aa9fc2a435a Revert "mm, memory_hotplug: initialize struct.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=1101382f40 > > kernel config: https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20 > > dashboard link: https://syzkaller.appspot.com/bug?extid=ca95b2b7aef9e7cbd6ab > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > Unfortunately, I don't have any reproducer for this crash yet. > > Not understanding. That seems to be saying that we got a NULL pointer > deref in __generic_file_write_iter() at > > written = generic_perform_write(file, from, iocb->ki_pos); > > which isn't possible. > > I'm not seeing recent changes in there which could have caused this. Help. + Maybe the problem is that the frame pointer unwinder isn't designed to cope with NULL function pointers - or more generally, with an unwinding operation that starts before the function's frame pointer has been set up? Unwinding starts at show_trace_log_lvl(). That begins with unwind_start(), which calls __unwind_start(), which uses get_frame_pointer(), which just returns regs->bp. But that frame pointer points to the part of the stack that's storing the address of the caller of the function that called NULL; the caller of NULL is skipped, as far as I can tell. What's kind of annoying here is that we don't have a proper frame set up yet, we only have half a stack frame (saved RIP but no saved RBP). > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+ca95b2b7aef9e7cbd...@syzkaller.appspotmail.com > > > > BUG: unable to handle kernel NULL pointer dereference at > > #PF error: [INSTR] > > PGD a7ea0067 P4D a7ea0067 PUD 81535067 PMD 0 > > Oops: 0010 [#1] PREEMPT SMP KASAN > > CPU: 0 PID: 15924 Comm: syz-executor0 Not tainted 5.0.0-rc4+ #50 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > RIP: 0010: (null) > > Code: Bad RIP value. > > RSP: 0018:88804c3d7858 EFLAGS: 00010246 > > RAX: RBX: 885aeb60 RCX: 005b > > RDX: RSI: 88807ec22930 RDI: 8880a59bdcc0 > > RBP: 88804c3d79b8 R08: R09: 88804c3d7910 > > R10: 8880835ca200 R11: R12: 005b > > R13: 88804c3d7c98 R14: dc00 R15: > > FS: 7f3456db4700() GS:8880ae60() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: ffd6 CR3: 814ac000 CR4: 001406f0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > Call Trace: > > __generic_file_write_iter+0x25e/0x630 mm/filemap.c: > > ext4_file_write_iter+0x37a/0x1410 fs/ext4/file.c:266 > > call_write_iter include/linux/fs.h:1862 [inline] > > new_sync_write fs/read_write.c:474 [inline] > > __vfs_write+0x764/0xb40 fs/read_write.c:487 > > vfs_write+0x20c/0x580 fs/read_write.c:549 > > ksys_write+0x105/0x260 fs/read_write.c:598 > > __do_sys_write fs/read_write.c:610 [inline] > > __se_sys_write fs/read_write.c:607 [inline] > > __x64_sys_write+0x73/0xb0 fs/read_write.c:607 > > do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > RIP: 0033:0x458089 > > Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > > RSP: 002b:7f3456db3c78 EFLAGS: 0246 ORIG_RAX: 0001 > > RAX: ffda RBX: 0003 RCX: 00458089 > > RDX: 005b RSI: 2240 RDI: 0003 > > RBP: 0073bf00 R08: R09: > > R10: R11: 0246 R12: 7f3456db46d4 > > R13: 004c7450 R14: 004dce68 R15: > > Modules linked in: > > CR2: > > ---[ end trace 5cac9d2c75a59916 ]--- > > kobject: 'loop5' (4426a409): kobject_uevent_env > > RIP: 0010: (null) > > Code: Bad
Re: BUG: unable to handle kernel NULL pointer dereference in __generic_file_write_iter
On Thu, 21 Feb 2019 06:52:04 -0800 syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:4aa9fc2a435a Revert "mm, memory_hotplug: initialize struct.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1101382f40 > kernel config: https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20 > dashboard link: https://syzkaller.appspot.com/bug?extid=ca95b2b7aef9e7cbd6ab > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. Not understanding. That seems to be saying that we got a NULL pointer deref in __generic_file_write_iter() at written = generic_perform_write(file, from, iocb->ki_pos); which isn't possible. I'm not seeing recent changes in there which could have caused this. Help. > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+ca95b2b7aef9e7cbd...@syzkaller.appspotmail.com > > BUG: unable to handle kernel NULL pointer dereference at > #PF error: [INSTR] > PGD a7ea0067 P4D a7ea0067 PUD 81535067 PMD 0 > Oops: 0010 [#1] PREEMPT SMP KASAN > CPU: 0 PID: 15924 Comm: syz-executor0 Not tainted 5.0.0-rc4+ #50 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010: (null) > Code: Bad RIP value. > RSP: 0018:88804c3d7858 EFLAGS: 00010246 > RAX: RBX: 885aeb60 RCX: 005b > RDX: RSI: 88807ec22930 RDI: 8880a59bdcc0 > RBP: 88804c3d79b8 R08: R09: 88804c3d7910 > R10: 8880835ca200 R11: R12: 005b > R13: 88804c3d7c98 R14: dc00 R15: > FS: 7f3456db4700() GS:8880ae60() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: ffd6 CR3: 814ac000 CR4: 001406f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > __generic_file_write_iter+0x25e/0x630 mm/filemap.c: > ext4_file_write_iter+0x37a/0x1410 fs/ext4/file.c:266 > call_write_iter include/linux/fs.h:1862 [inline] > new_sync_write fs/read_write.c:474 [inline] > __vfs_write+0x764/0xb40 fs/read_write.c:487 > vfs_write+0x20c/0x580 fs/read_write.c:549 > ksys_write+0x105/0x260 fs/read_write.c:598 > __do_sys_write fs/read_write.c:610 [inline] > __se_sys_write fs/read_write.c:607 [inline] > __x64_sys_write+0x73/0xb0 fs/read_write.c:607 > do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x458089 > Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7f3456db3c78 EFLAGS: 0246 ORIG_RAX: 0001 > RAX: ffda RBX: 0003 RCX: 00458089 > RDX: 005b RSI: 2240 RDI: 0003 > RBP: 0073bf00 R08: R09: > R10: R11: 0246 R12: 7f3456db46d4 > R13: 004c7450 R14: 004dce68 R15: > Modules linked in: > CR2: > ---[ end trace 5cac9d2c75a59916 ]--- > kobject: 'loop5' (4426a409): kobject_uevent_env > RIP: 0010: (null) > Code: Bad RIP value. > RSP: 0018:88804c3d7858 EFLAGS: 00010246 > RAX: RBX: 885aeb60 RCX: 005b > kobject: 'loop5' (4426a409): fill_kobj_path: path > = '/devices/virtual/block/loop5' > RDX: RSI: 88807ec22930 RDI: 8880a59bdcc0 > kobject: 'loop2' (b82e0c58): kobject_uevent_env > kobject: 'loop2' (b82e0c58): fill_kobj_path: path > = '/devices/virtual/block/loop2' > RBP: 88804c3d79b8 R08: R09: 88804c3d7910 > R10: 8880835ca200 R11: R12: 005b > R13: 88804c3d7c98 R14: dc00 R15: > kobject: 'loop5' (4426a409): kobject_uevent_env > FS: 7f3456db4700() GS:8880ae60() knlGS: > kobject: 'loop5' (4426a409): fill_kobj_path: path > = '/devices/virtual/block/loop5' > CS: 0010 DS: ES: CR0: 80050033 > CR2: 022029a0 CR3: 814ac000 CR4: 001406f0 > DR0: DR1: DR2:
BUG: unable to handle kernel NULL pointer dereference in __generic_file_write_iter
Hello, syzbot found the following crash on: HEAD commit:4aa9fc2a435a Revert "mm, memory_hotplug: initialize struct.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1101382f40 kernel config: https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20 dashboard link: https://syzkaller.appspot.com/bug?extid=ca95b2b7aef9e7cbd6ab compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+ca95b2b7aef9e7cbd...@syzkaller.appspotmail.com BUG: unable to handle kernel NULL pointer dereference at #PF error: [INSTR] PGD a7ea0067 P4D a7ea0067 PUD 81535067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 15924 Comm: syz-executor0 Not tainted 5.0.0-rc4+ #50 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010: (null) Code: Bad RIP value. RSP: 0018:88804c3d7858 EFLAGS: 00010246 RAX: RBX: 885aeb60 RCX: 005b RDX: RSI: 88807ec22930 RDI: 8880a59bdcc0 RBP: 88804c3d79b8 R08: R09: 88804c3d7910 R10: 8880835ca200 R11: R12: 005b R13: 88804c3d7c98 R14: dc00 R15: FS: 7f3456db4700() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 814ac000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __generic_file_write_iter+0x25e/0x630 mm/filemap.c: ext4_file_write_iter+0x37a/0x1410 fs/ext4/file.c:266 call_write_iter include/linux/fs.h:1862 [inline] new_sync_write fs/read_write.c:474 [inline] __vfs_write+0x764/0xb40 fs/read_write.c:487 vfs_write+0x20c/0x580 fs/read_write.c:549 ksys_write+0x105/0x260 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:607 do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x458089 Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f3456db3c78 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: 0003 RCX: 00458089 RDX: 005b RSI: 2240 RDI: 0003 RBP: 0073bf00 R08: R09: R10: R11: 0246 R12: 7f3456db46d4 R13: 004c7450 R14: 004dce68 R15: Modules linked in: CR2: ---[ end trace 5cac9d2c75a59916 ]--- kobject: 'loop5' (4426a409): kobject_uevent_env RIP: 0010: (null) Code: Bad RIP value. RSP: 0018:88804c3d7858 EFLAGS: 00010246 RAX: RBX: 885aeb60 RCX: 005b kobject: 'loop5' (4426a409): fill_kobj_path: path = '/devices/virtual/block/loop5' RDX: RSI: 88807ec22930 RDI: 8880a59bdcc0 kobject: 'loop2' (b82e0c58): kobject_uevent_env kobject: 'loop2' (b82e0c58): fill_kobj_path: path = '/devices/virtual/block/loop2' RBP: 88804c3d79b8 R08: R09: 88804c3d7910 R10: 8880835ca200 R11: R12: 005b R13: 88804c3d7c98 R14: dc00 R15: kobject: 'loop5' (4426a409): kobject_uevent_env FS: 7f3456db4700() GS:8880ae60() knlGS: kobject: 'loop5' (4426a409): fill_kobj_path: path = '/devices/virtual/block/loop5' CS: 0010 DS: ES: CR0: 80050033 CR2: 022029a0 CR3: 814ac000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
oops:BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
Hi, My OS with V2.6.32 kernel capture an Oops: 2019-02-09T07:10:38.566968+08:00 nw-nhis1 kernel: [7972630.613854] BUG: unable to handle kernel NULL pointer dereference at 00a8 2019-02-09T07:10:38.566992+08:00 nw-nhis1 kernel: [7972630.613859] IP: [] next_tgid+0x5f/0x82 2019-02-09T07:10:38.566999+08:00 nw-nhis1 kernel: [7972630.613865] PGD 21dae1067 PUD 21c1fc067 PMD 0 2019-02-09T07:10:38.567002+08:00 nw-nhis1 kernel: [7972630.613869] Oops: [#1] SMP 2019-02-09T07:10:38.567005+08:00 nw-nhis1 kernel: [7972630.613871] last sysfs file: /sys/devices/pci:40/:40:02.0/:41:00.0/host6/rport-6:0-6/target6:0:3/6:0:3:2/state 2019-02-09T07:10:38.567008+08:00 nw-nhis1 kernel: [7972630.613873] CPU 0 2019-02-09T07:10:38.567016+08:00 nw-nhis1 kernel: [7972630.613875] Modules linked in: xfs exportfs fuse dm_round_robin dm_snapshot ipmi_watchdog ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler dm_mirror dm_region_hash dm_log bonding ipv6 dm_multipath scsi_dh lsm_linx snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd igb i2c_piix4 serio_raw dca joydev button ext3 jbd raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0 multipath linear md_mod dm_mod lpfc ahci scsi_transport_fc ohci_hcd libata scsi_tgt megaraid_sas [last unloaded: scsi_wait_scan] 2019-02-09T07:10:38.567021+08:00 nw-nhis1 kernel: [7972630.613903] Pid: 5224, comm: dmserver Tainted: G W 2.6.32.41-Rocky4.2-x86_64 #1 A840-G10 2019-02-09T07:10:38.567024+08:00 nw-nhis1 kernel: [7972630.613905] RIP: 0010:[] [] next_tgid+0x5f/0x82 2019-02-09T07:10:38.567027+08:00 nw-nhis1 kernel: [7972630.613909] RSP: 0018:88021b5e3df8 EFLAGS: 00010282 2019-02-09T07:10:38.567029+08:00 nw-nhis1 kernel: [7972630.613911] RAX: RBX: 81576080 RCX: 0034 2019-02-09T07:10:38.567032+08:00 nw-nhis1 kernel: [7972630.613913] RDX: 880a87c6eae0 RSI: RDI: 880c1ca8b800 2019-02-09T07:10:38.567034+08:00 nw-nhis1 kernel: [7972630.613914] RBP: 13e2 R08: 4000 R09: a310 2019-02-09T07:10:38.567037+08:00 nw-nhis1 kernel: [7972630.613916] R10: R11: 0246 R12: 880c1ca8b800 2019-02-09T07:10:38.567040+08:00 nw-nhis1 kernel: [7972630.613918] R13: 810fb720 R14: 88101e0bce60 R15: 88021b5e3f38 2019-02-09T07:10:38.567043+08:00 nw-nhis1 kernel: [7972630.613920] FS: 466ff940(0063) GS:880008c0() knlGS: 2019-02-09T07:10:38.567046+08:00 nw-nhis1 kernel: [7972630.613922] CS: 0010 DS: ES: CR0: 80050033 2019-02-09T07:10:38.567048+08:00 nw-nhis1 kernel: [7972630.613924] CR2: 00a8 CR3: 00021caf3000 CR4: 000406f0 2019-02-09T07:10:38.567051+08:00 nw-nhis1 kernel: [7972630.613925] DR0: DR1: DR2: 2019-02-09T07:10:38.567054+08:00 nw-nhis1 kernel: [7972630.613927] DR3: DR6: 0ff0 DR7: 0400 2019-02-09T07:10:38.567062+08:00 nw-nhis1 kernel: [7972630.613929] Process dmserver (pid: 5224, threadinfo 88021b5e2000, task 8801030e4e60) 2019-02-09T07:10:38.567064+08:00 nw-nhis1 kernel: [7972630.613931] Stack: 2019-02-09T07:10:38.567066+08:00 nw-nhis1 kernel: [7972630.613932] 000400cf8c68 88021b5e3e98 880213d4 88101e0bce60 2019-02-09T07:10:38.567070+08:00 nw-nhis1 kernel: [7972630.613935] <0> 880a13d3 880a1f03 88018f43a700 880a13d3 2019-02-09T07:10:38.567072+08:00 nw-nhis1 kernel: [7972630.613937] <0> 880a1f03 81134f3b 88101e0bce60 2019-02-09T07:10:38.567075+08:00 nw-nhis1 kernel: [7972630.613941] Call Trace: 2019-02-09T07:10:38.567078+08:00 nw-nhis1 kernel: [7972630.613944] [] ? proc_pid_readdir+0x15c/0x1b6 2019-02-09T07:10:38.567081+08:00 nw-nhis1 kernel: [7972630.613947] [] ? filldir64+0x0/0xb9 2019-02-09T07:10:38.567083+08:00 nw-nhis1 kernel: [7972630.613949] [] ? filldir64+0x0/0xb9 2019-02-09T07:10:38.567086+08:00 nw-nhis1 kernel: [7972630.613952] [] ? vfs_readdir+0x6d/0xaa 2019-02-09T07:10:38.567089+08:00 nw-nhis1 kernel: [7972630.613955] [] ? sys_getdents64+0x77/0xbf 2019-02-09T07:10:38.567092+08:00 nw-nhis1 kernel: [7972630.613957] [] ? system_call_fastpath+0x16/0x1b 2019-02-09T07:10:38.567096+08:00 nw-nhis1 kernel: [7972630.613959] Code: 04 31 d2 eb 3e 48 89 de 48 89 c7 e8 2d b9 f2 ff 31 f6 4c 89 e7 89 c5 e8 af b8 f2 ff 48 85 c0 48 89 c2 74 17 48 8b 80 c8 04 00 00 <48> 8b 88 a8 00 00 00 48 39 8a 78 02 00 00 74 04 ff c5 eb b0 f0 2019-02-09T07:10:38.567099+08:00 nw-nhis1 kernel: [7972630.613979] RIP [] next_tgid+0x5f/0x82 2019-02-09T07:10:38.567102+08:00 nw-nhis1 kernel: [7972630.613981] RSP 2019-02-09T07:10:38.567104+08:00 nw-nhis1 kernel: [7972630.613983] CR2: 00a8 2019-02-09T07:10:38.567107+08:00 nw-nhis1 kernel: [7972630.61407
Re: bpf: test_tunnel.sh: BUG: unable to handle kernel NULL pointer dereference
On Fri, 1 Feb 2019, Naresh Kamboju wrote: > Kernel panic while running bpf: test_tunnel.sh on linux -next > 5.0.0-rc4-next-20190129. > > selftests: bpf: test_tunnel.sh > [ 273.997647] IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready > [ 274.054068] ip (11458) used greatest stack depth: 11448 bytes left > [ 274.120445] BUG: unable to handle kernel NULL pointer dereference > at > [ 274.128285] #PF error: [INSTR] > [ 274.131351] PGD 800414a0e067 P4D 800414a0e067 PUD 3b6334067 PMD 0 > [ 274.138241] Oops: 0010 [#1] SMP PTI > [ 274.141734] CPU: 1 PID: 11464 Comm: ping Not tainted > 5.0.0-rc4-next-20190129 #1 > [ 274.149046] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS > 2.0b 07/27/2017 > [ 274.156526] RIP: 0010: (null) > [ 274.160280] Code: Bad RIP value. > [ 274.163509] RSP: 0018:bc9681f83540 EFLAGS: 00010286 > [ 274.168726] RAX: RBX: dc967fa80a18 RCX: > > [ 274.175851] RDX: 9db2ee08b540 RSI: 000e RDI: > dc967fa809a0 > [ 274.182974] RBP: bc9681f83580 R08: 9db2c4d62690 R09: > 000c > [ 274.190098] R10: R11: 9db2ee08b540 R12: > 9db31ce7c000 > [ 274.197222] R13: 0001 R14: 000c R15: > 9db3179cf400 > [ 274.204346] FS: 7ff4ae7c5740() GS:9db31fa8() > knlGS: > [ 274.212424] CS: 0010 DS: ES: CR0: 80050033 > [ 274.218162] CR2: ffd6 CR3: 0004574da004 CR4: > 003606e0 > [ 274.225292] DR0: DR1: DR2: > > [ 274.232416] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 274.239541] Call Trace: > [ 274.241988] ? tnl_update_pmtu+0x296/0x3b0 > [ 274.246085] ip_md_tunnel_xmit+0x1bc/0x520 > [ 274.250176] gre_fb_xmit+0x330/0x390 > [ 274.253754] gre_tap_xmit+0x128/0x180 > [ 274.257414] dev_hard_start_xmit+0xb7/0x300 > [ 274.261598] sch_direct_xmit+0xf6/0x290 > [ 274.265430] __qdisc_run+0x15d/0x5e0 > [ 274.269007] __dev_queue_xmit+0x2c5/0xc00 > [ 274.273011] ? dev_queue_xmit+0x10/0x20 > [ 274.276842] ? eth_header+0x2b/0xc0 > [ 274.280326] dev_queue_xmit+0x10/0x20 > [ 274.283984] ? dev_queue_xmit+0x10/0x20 > [ 274.287813] arp_xmit+0x1a/0xf0 > [ 274.290952] arp_send_dst.part.19+0x46/0x60 > [ 274.295138] arp_solicit+0x177/0x6b0 > [ 274.298708] ? mod_timer+0x18e/0x440 > [ 274.302281] neigh_probe+0x57/0x70 > [ 274.305684] __neigh_event_send+0x197/0x2d0 > [ 274.309862] neigh_resolve_output+0x18c/0x210 > [ 274.314212] ip_finish_output2+0x257/0x690 > [ 274.318304] ip_finish_output+0x219/0x340 > [ 274.322314] ? ip_finish_output+0x219/0x340 > [ 274.326493] ip_output+0x76/0x240 > [ 274.329805] ? ip_fragment.constprop.53+0x80/0x80 > [ 274.334510] ip_local_out+0x3f/0x70 > [ 274.337992] ip_send_skb+0x19/0x40 > [ 274.341391] ip_push_pending_frames+0x33/0x40 > [ 274.345740] raw_sendmsg+0xc15/0x11d0 > [ 274.349403] ? __might_fault+0x85/0x90 > [ 274.353151] ? _copy_from_user+0x6b/0xa0 > [ 274.357070] ? rw_copy_check_uvector+0x54/0x130 > [ 274.361604] inet_sendmsg+0x42/0x1c0 > [ 274.365179] ? inet_sendmsg+0x42/0x1c0 > [ 274.368937] sock_sendmsg+0x3e/0x50 > [ 274.372460] ___sys_sendmsg+0x26f/0x2d0 > [ 274.376293] ? lock_acquire+0x95/0x190 > [ 274.380043] ? __handle_mm_fault+0x7ce/0xb70 > [ 274.384307] ? lock_acquire+0x95/0x190 > [ 274.388053] ? __audit_syscall_entry+0xdd/0x130 > [ 274.392586] ? ktime_get_coarse_real_ts64+0x64/0xc0 > [ 274.397461] ? __audit_syscall_entry+0xdd/0x130 > [ 274.401989] ? trace_hardirqs_on+0x4c/0x100 > [ 274.406173] __sys_sendmsg+0x63/0xa0 > [ 274.409744] ? __sys_sendmsg+0x63/0xa0 > [ 274.413488] __x64_sys_sendmsg+0x1f/0x30 > [ 274.417405] do_syscall_64+0x55/0x190 > [ 274.421064] entry_SYSCALL_64_after_hwframe+0x49/0xbe > [ 274.426113] RIP: 0033:0x7ff4ae0e6e87 > [ 274.429686] Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00 > 00 00 00 8b 05 ca d9 2b 00 48 63 d2 48 63 ff 85 c0 75 10 b8 2e 00 00 > 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 53 48 89 f3 48 83 ec 10 48 89 7c > 24 08 > [ 274.448422] RSP: 002b:7ffcd9b76db8 EFLAGS: 0246 ORIG_RAX: > 002e > [ 274.455978] RAX: ffda RBX: 0040 RCX: > 7ff4ae0e6e87 > [ 274.463104] RDX: RSI: 006092e0 RDI: > 0003 > [ 274.470228] RBP: R08: 7ffcd9bc40a0 R09: > 7ffcd9bc4080 > [ 274.477349] R10: 060a R11: 0246 R12: > 0003 > [ 274.484475] R13: 0016 R14: 7ff
bpf: test_tunnel.sh: BUG: unable to handle kernel NULL pointer dereference
Kernel panic while running bpf: test_tunnel.sh on linux -next 5.0.0-rc4-next-20190129. selftests: bpf: test_tunnel.sh [ 273.997647] IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready [ 274.054068] ip (11458) used greatest stack depth: 11448 bytes left [ 274.120445] BUG: unable to handle kernel NULL pointer dereference at [ 274.128285] #PF error: [INSTR] [ 274.131351] PGD 800414a0e067 P4D 800414a0e067 PUD 3b6334067 PMD 0 [ 274.138241] Oops: 0010 [#1] SMP PTI [ 274.141734] CPU: 1 PID: 11464 Comm: ping Not tainted 5.0.0-rc4-next-20190129 #1 [ 274.149046] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS 2.0b 07/27/2017 [ 274.156526] RIP: 0010: (null) [ 274.160280] Code: Bad RIP value. [ 274.163509] RSP: 0018:bc9681f83540 EFLAGS: 00010286 [ 274.168726] RAX: RBX: dc967fa80a18 RCX: [ 274.175851] RDX: 9db2ee08b540 RSI: 000e RDI: dc967fa809a0 [ 274.182974] RBP: bc9681f83580 R08: 9db2c4d62690 R09: 000c [ 274.190098] R10: R11: 9db2ee08b540 R12: 9db31ce7c000 [ 274.197222] R13: 0001 R14: 000c R15: 9db3179cf400 [ 274.204346] FS: 7ff4ae7c5740() GS:9db31fa8() knlGS: [ 274.212424] CS: 0010 DS: ES: CR0: 80050033 [ 274.218162] CR2: ffd6 CR3: 0004574da004 CR4: 003606e0 [ 274.225292] DR0: DR1: DR2: [ 274.232416] DR3: DR6: fffe0ff0 DR7: 0400 [ 274.239541] Call Trace: [ 274.241988] ? tnl_update_pmtu+0x296/0x3b0 [ 274.246085] ip_md_tunnel_xmit+0x1bc/0x520 [ 274.250176] gre_fb_xmit+0x330/0x390 [ 274.253754] gre_tap_xmit+0x128/0x180 [ 274.257414] dev_hard_start_xmit+0xb7/0x300 [ 274.261598] sch_direct_xmit+0xf6/0x290 [ 274.265430] __qdisc_run+0x15d/0x5e0 [ 274.269007] __dev_queue_xmit+0x2c5/0xc00 [ 274.273011] ? dev_queue_xmit+0x10/0x20 [ 274.276842] ? eth_header+0x2b/0xc0 [ 274.280326] dev_queue_xmit+0x10/0x20 [ 274.283984] ? dev_queue_xmit+0x10/0x20 [ 274.287813] arp_xmit+0x1a/0xf0 [ 274.290952] arp_send_dst.part.19+0x46/0x60 [ 274.295138] arp_solicit+0x177/0x6b0 [ 274.298708] ? mod_timer+0x18e/0x440 [ 274.302281] neigh_probe+0x57/0x70 [ 274.305684] __neigh_event_send+0x197/0x2d0 [ 274.309862] neigh_resolve_output+0x18c/0x210 [ 274.314212] ip_finish_output2+0x257/0x690 [ 274.318304] ip_finish_output+0x219/0x340 [ 274.322314] ? ip_finish_output+0x219/0x340 [ 274.326493] ip_output+0x76/0x240 [ 274.329805] ? ip_fragment.constprop.53+0x80/0x80 [ 274.334510] ip_local_out+0x3f/0x70 [ 274.337992] ip_send_skb+0x19/0x40 [ 274.341391] ip_push_pending_frames+0x33/0x40 [ 274.345740] raw_sendmsg+0xc15/0x11d0 [ 274.349403] ? __might_fault+0x85/0x90 [ 274.353151] ? _copy_from_user+0x6b/0xa0 [ 274.357070] ? rw_copy_check_uvector+0x54/0x130 [ 274.361604] inet_sendmsg+0x42/0x1c0 [ 274.365179] ? inet_sendmsg+0x42/0x1c0 [ 274.368937] sock_sendmsg+0x3e/0x50 [ 274.372460] ___sys_sendmsg+0x26f/0x2d0 [ 274.376293] ? lock_acquire+0x95/0x190 [ 274.380043] ? __handle_mm_fault+0x7ce/0xb70 [ 274.384307] ? lock_acquire+0x95/0x190 [ 274.388053] ? __audit_syscall_entry+0xdd/0x130 [ 274.392586] ? ktime_get_coarse_real_ts64+0x64/0xc0 [ 274.397461] ? __audit_syscall_entry+0xdd/0x130 [ 274.401989] ? trace_hardirqs_on+0x4c/0x100 [ 274.406173] __sys_sendmsg+0x63/0xa0 [ 274.409744] ? __sys_sendmsg+0x63/0xa0 [ 274.413488] __x64_sys_sendmsg+0x1f/0x30 [ 274.417405] do_syscall_64+0x55/0x190 [ 274.421064] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 274.426113] RIP: 0033:0x7ff4ae0e6e87 [ 274.429686] Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00 00 00 00 8b 05 ca d9 2b 00 48 63 d2 48 63 ff 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 53 48 89 f3 48 83 ec 10 48 89 7c 24 08 [ 274.448422] RSP: 002b:7ffcd9b76db8 EFLAGS: 0246 ORIG_RAX: 002e [ 274.455978] RAX: ffda RBX: 0040 RCX: 7ff4ae0e6e87 [ 274.463104] RDX: RSI: 006092e0 RDI: 0003 [ 274.470228] RBP: R08: 7ffcd9bc40a0 R09: 7ffcd9bc4080 [ 274.477349] R10: 060a R11: 0246 R12: 0003 [ 274.484475] R13: 0016 R14: 7ffcd9b77fa0 R15: 7ffcd9b78da4 [ 274.491602] Modules linked in: cls_bpf sch_ingress iptable_filter ip_tables algif_hash af_alg x86_pkg_temp_thermal fuse [last unloaded: test_bpf] [ 274.504634] CR2: [ 274.507976] ---[ end trace 196d18386545eae1 ]--- [ 274.512588] RIP: 0010: (null) [ 274.516334] Code: Bad RIP value. [ 274.519557] RSP: 0018:bc9681f83540 EFLAGS: 00010286 [ 274.524775] RAX: RBX: dc967fa80a18 RCX: [ 274.531921] RDX: 9db2ee08b540 RSI: 000e RDI: dc967f
c438cfd46e ("blk-mq: fix changelog"): BUG: unable to handle kernel NULL pointer dereference at 00000000
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git debugfs_cleanup commit c438cfd46e37a6dd9e370219a6f0d397cc3c1a36 Author: Greg Kroah-Hartman AuthorDate: Fri Jan 4 14:06:22 2019 +0100 Commit: Greg Kroah-Hartman CommitDate: Thu Jan 31 14:18:25 2019 +0100 blk-mq: fix changelog ddd7d0ff2d wireless: fix changelog c438cfd46e blk-mq: fix changelog 31b092d47f lib: WIP, break up +--++++ | | ddd7d0ff2d | c438cfd46e | 31b092d47f | +--++++ | boot_successes | 37 | 0 | 0 | | boot_failures| 0 | 26 | 26 | | BUG:unable_to_handle_kernel | 0 | 26 | 26 | | Oops:#[##] | 0 | 26 | 26 | | EIP:debugfs_create_files | 0 | 26 | 26 | | Kernel_panic-not_syncing:Fatal_exception | 0 | 26 | 26 | +--++++ [7.740649] igt_debug 0x0a00-0x0e00: 1024: used [7.741350] igt_debug 0x0e00-0x1000: 512: free [7.742149] igt_debug total: 4096, used 2048 free 2048 [ 42.726577] [drm] Initialized vgem 1.0.0 20120112 for vgem on minor 0 [ 42.728241] Floppy drive(s): fd0 is 2.88M AMI BIOS [ 42.729334] BUG: unable to handle kernel NULL pointer dereference at [ 42.729735] #PF error: [normal kernel read fault] [ 42.729735] *pde = [ 42.729735] Oops: [#1] [ 42.729735] CPU: 0 PID: 1 Comm: swapper Not tainted 5.0.0-rc2-00115-gc438cfd #113 [ 42.729735] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 42.729735] EIP: debugfs_create_files+0x6b/0xa0 [ 42.729735] Code: 00 00 00 00 0f 97 c0 31 c9 89 c7 0f b6 d0 b8 68 ab 7b 82 e8 57 6d be ff 89 f8 84 c0 75 38 8b 46 30 8b 7d f0 89 b8 fc 01 00 00 <8b> 03 85 c0 74 26 8d b4 26 00 00 00 00 0f b7 53 04 89 1c 24 89 f1 [ 42.729735] EAX: 9efb5000 EBX: ECX: EDX: [ 42.729735] ESI: 9efb3840 EDI: 9d6cf800 EBP: 80243e3c ESP: 80243e24 [ 42.729735] DS: 007b ES: 007b FS: GS: SS: 0068 EFLAGS: 00210246 [ 42.729735] CR0: 80050033 CR2: CR3: 02924000 CR4: 001406d0 [ 42.729735] Call Trace: [ 42.729735] blk_mq_debugfs_register_sched_hctx+0x34/0x40 [ 42.729735] blk_mq_debugfs_register+0xb1/0xc0 [ 42.729735] blk_register_queue+0x108/0x230 [ 42.729735] __device_add_disk+0x44f/0x640 [ 42.729735] device_add_disk+0x17/0x20 [ 42.729735] loop_add+0x217/0x2c0 [ 42.729735] loop_init+0xf9/0x11a [ 42.729735] ? floppy_async_init+0xd4c/0xd4c [ 42.729735] do_one_initcall+0xdd/0x25d [ 42.729735] kernel_init_freeable+0x25a/0x2d7 [ 42.729735] ? rest_init+0x140/0x140 [ 42.729735] kernel_init+0x10/0x100 [ 42.729735] ? schedule_tail_wrapper+0x9/0x10 [ 42.729735] ret_from_fork+0x19/0x30 [ 42.729735] CR2: [ 42.729735] _warn_unseeded_randomness: 35 callbacks suppressed [ 42.729735] random: get_random_bytes called from init_oops_id+0x3f/0x50 with crng_init=1 [ 42.729735] ---[ end trace 25be250042fb0fd4 ]--- [ 42.729735] EIP: debugfs_create_files+0x6b/0xa0 # HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD git bisect start 0e9ac1e5b38fa1032c8809b7f375c5f20aa8c2be f17b5f06cb92ef2250513a1e154c47b78df07d40 -- git bisect good f095dea55a4ac7fdb83f505523ad417274e54192 # 01:00 G 10 00 0 Merge 'ulf.hansson-mmc/next' into devel-catchup-201901312352 git bisect good f1ac64a048ea54cd0bfa9d1d455056c135e3e597 # 01:08 G 11 00 0 Merge 'alaahl/for-linust' into devel-catchup-201901312352 git bisect bad 4f28883ea4af13b4d15f7ae2f7efb5fa81cc4f84 # 01:14 B 0 9 34 11 Merge 'driver-core/debugfs_cleanup' into devel-catchup-201901312352 git bisect good 52c070b7c8809576d3065d4b6a4cf1154d7acde2 # 01:33 G 10 00 0 cw1200: no need to check return value of debugfs_create functions git bisect good 3000a51bc760ad362eeab65de07a92c47b2353eb # 01:43 G 10 00 0 f2fs: no need to check return value of debugfs_create functions git bisect good 50b82e5dd6c2fad0af36a80baff41b37c18e091b # 02:00 G 11 00 0 xen-netback: fix changelog git bisect bad 6a37bbef02b8607940a432c864e3f635293cb1e3 # 02:04 B 0 2 16 0 pstore: fix changelog git bisect good c3cbe3160fcb8ea6dc6a6d2939af4f2bf05c11a2 # 02:29 G 11 00 0 sunrpc: fix changelog git bisect good ddd7d0ff2d7b4f80e2c4b54
1aba551c73 ("blk-mq: fix changelog"): BUG: unable to handle kernel NULL pointer dereference at 00000000
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git debugfs_cleanup commit 1aba551c73de605983515118d5ad527594440ccb Author: Greg Kroah-Hartman AuthorDate: Fri Jan 4 14:06:22 2019 +0100 Commit: Greg Kroah-Hartman CommitDate: Sat Jan 5 18:42:10 2019 +0100 blk-mq: fix changelog 7d7009c53a wireless: fix changelog 1aba551c73 blk-mq: fix changelog 6044acd966 lib: WIP, break up +--++++ | | 7d7009c53a | 1aba551c73 | 6044acd966 | +--++++ | boot_successes | 32 | 0 | 0 | | boot_failures| 0 | 22 | 19 | | BUG:unable_to_handle_kernel | 0 | 22 | 19 | | Oops:#[##] | 0 | 22 | 19 | | EIP:debugfs_create_files | 0 | 22 | 19 | | Kernel_panic-not_syncing:Fatal_exception | 0 | 22 | 19 | +--++++ [ 19.240778] parport_pc 00:04: reported by Plug and Play ACPI [ 19.249983] parport0: PC-style at 0x378, irq 7 [PCSPP(,...)] [ 19.259854] lp0: using parport0 (interrupt-driven). [ 19.266789] lp0: console ready [ 19.294331] brd: module loaded [ 19.303672] BUG: unable to handle kernel NULL pointer dereference at [ 19.311670] #PF error: [normal kernel read fault] [ 19.312646] *pdpt = *pde = f000ff53f000ff53 [ 19.312646] Oops: [#1] PTI [ 19.312646] CPU: 0 PID: 1 Comm: swapper Tainted: GT 4.20.0-11094-g1aba551 #440 [ 19.312646] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 19.312646] EIP: debugfs_create_files+0x20/0x60 [ 19.312646] Code: 74 26 00 8d bc 27 00 00 00 00 55 89 e5 56 89 c6 53 83 ec 08 85 c0 74 42 3d 00 f0 ff ff 77 3b 8b 40 10 89 cb 89 90 a4 00 00 00 <8b> 01 85 c0 74 2a 8d 76 00 8d bc 27 00 00 00 00 0f b7 53 04 b9 00 [ 19.312646] EAX: db0c1ae0 EBX: ECX: EDX: d9f41400 [ 19.312646] ESI: db0aa500 EDI: d9f41400 EBP: db45be38 ESP: db45be28 [ 19.312646] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 EFLAGS: 00210287 [ 19.312646] CR0: 80050033 CR2: CR3: 028ca000 CR4: 001406f0 [ 19.312646] Call Trace: [ 19.312646] blk_mq_debugfs_register_sched_hctx+0x36/0x40 [ 19.312646] blk_mq_debugfs_register+0xb1/0xd0 [ 19.312646] blk_register_queue+0xa1/0x170 [ 19.312646] __device_add_disk+0x2af/0x4a0 [ 19.312646] device_add_disk+0x12/0x20 [ 19.312646] loop_add+0x1b9/0x240 [ 19.312646] loop_init+0xfd/0x12f [ 19.312646] ? brd_init+0x15c/0x15c [ 19.312646] do_one_initcall+0x68/0x134 [ 19.312646] ? loglevel+0x47/0x47 [ 19.312646] kernel_init_freeable+0xe1/0x15b [ 19.312646] ? rest_init+0x90/0x90 [ 19.312646] kernel_init+0xb/0x100 [ 19.312646] ? schedule_tail_wrapper+0x9/0x10 [ 19.312646] ret_from_fork+0x19/0x30 [ 19.312646] CR2: [ 19.312646] ---[ end trace 3fa233f5a018a515 ]--- [ 19.312646] EIP: debugfs_create_files+0x20/0x60 # HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD git bisect start 6044acd966af9b2abf150dde97c9092e174f5c32 3fed6ae4b027f9c93be18520f87bd06bdffd196b -- git bisect good 9e34cf7c199ca0088d4704b5c246a915ed336419 # 03:36 G 11 00 0 ti: wl1251: no need to check return value of debugfs_create functions git bisect good 2b1612f9f11109c49b327401b9deb5e7f42ae9aa # 03:48 G 11 00 2 gcov: no need to check return value of debugfs_create functions git bisect good ea485bd98e3c0b4a8ace4f43a6099b28ac37d62d # 03:59 G 11 00 0 l2tp: fix changelog git bisect bad 4f6a5da79aa189934d6ff9244efccb4e166d4648 # 04:11 B 0 10 31 7 gfs: no need to check return value of debugfs_create functions git bisect good 7d7009c53a3be411a6a790ac2788677db27d7286 # 04:24 G 11 00 0 wireless: fix changelog git bisect bad b73f975f76e48705feb505327cd888bb0ec9eb14 # 04:32 B 0 1 15 0 btrfs: no need to check return value of debugfs_create functions git bisect bad 1aba551c73de605983515118d5ad527594440ccb # 04:43 B 0 10 35 11 blk-mq: fix changelog # first bad commit: [1aba551c73de605983515118d5ad527594440ccb] blk-mq: fix changelog git bisect good 7d7009c53a3be411a6a790ac2788677db27d7286 # 04:48 G 30 00 0 wireless: fix changelog # extra tests with debug options git bisect bad 1aba551c73de605983515118d5ad527594440ccb # 05:00 B 0 11 25 0 blk-mq: fix changelog # extra tests on HEAD of drive