* linux-next boot error: general protection fault in __x64_sys_settimeofday @ 2019-11-14 10:55 syzbot 2019-11-14 12:35 ` Thomas Gleixner 0 siblings, 1 reply; 10+ messages in thread From: syzbot @ 2019-11-14 10:55 UTC (permalink / raw) To: john.stultz, linux-kernel, sboyd, syzkaller-bugs, tglx Hello, syzbot found the following crash on: HEAD commit: 8466d23e Add linux-next specific files for 20191114 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1057aa1ce00000 kernel config: https://syzkaller.appspot.com/x/.config?x=7b7e774ae4847760 dashboard link: https://syzkaller.appspot.com/bug?extid=dccce9b26ba09ca49966 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+dccce9b26ba09ca49966@syzkaller.appspotmail.com [^[[36minfo^[[39;49m] Using makefile-style concurrent boot in runlevel S. [....] Starting the hotplug events dispatcher: udevd[ 13.646252][ T4004] udevd[4004]: starting version 175 ^[[?25l^[[?1c^[7^[[1G[^[[32m ok ^[[39;49m^[8^[[?25h^[[?0c. [....] Synthesizing the initial hotplug events...udevd[4040]: rename '/dev/v4l/by-path/platform-vivid.0-video-index3.udev-tmp' '/dev/v4l/by-path/platform-vivid.0-video-index3' failed: No such file or directory ^[[?25l^[[?1c^[7[ 20.856469][ T4350] general protection fault: 0000 [#1] PREEMPT SMP KASAN [^[[1G 20.872048][ T4350] Hardware name: Google Google Comput[^[[32m ok ^[[39;49me Engine/Google Compute Engine, BIOS Google 01/01/2011 ^[8[ ^[[?25h^[[?0c done. 20.890197][ T4350] Code: 85 50 ff ff ff 85 c0 0f 85 50 01 00 00 e8 b8 cd 10 00 48 8b 85 48 ff ff ff 48 c1 e8 03 48 89 c2 48 b8 00 00 00 00 00 fc ff df <80> 3c 02 00 0f 85 8a 01 00 00 49 8b 74 24 08 bf 40 42 0f 00 48 89 [....] Waiting f[ 21.522563][ T4350] RIP: 0010:__do_sys_settimeofday kernel/time/time.c:210 [inline] [....] Waiting f[ 21.522563][ T4350] RIP: 0010:__se_sys_settimeofday kernel/time/time.c:199 [inline] [....] Waiting f[ 21.522563][ T4350] RIP: 0010:__x64_sys_settimeofday+0x170/0x320 kernel/time/time.c:199 or /dev to be fu[ 21.550076][ T4350] RSP: 0018:ffff888093d0fe58 EFLAGS: 00010206 lly populated...[ 21.557498][ T4350] RAX: dffffc0000000000 RBX: 1ffff110127a1fcd RCX: ffffffff8162e915 --- 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 syzkaller@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: linux-next boot error: general protection fault in __x64_sys_settimeofday 2019-11-14 10:55 linux-next boot error: general protection fault in __x64_sys_settimeofday syzbot @ 2019-11-14 12:35 ` Thomas Gleixner 2019-11-14 12:42 ` Dmitry Vyukov 0 siblings, 1 reply; 10+ messages in thread From: Thomas Gleixner @ 2019-11-14 12:35 UTC (permalink / raw) To: syzbot; +Cc: John Stultz, LKML, sboyd, syzkaller-bugs, x86, kasan-dev On Thu, 14 Nov 2019, syzbot wrote: From the full console output: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:__x64_sys_settimeofday+0x170/0x320 Code: 85 50 ff ff ff 85 c0 0f 85 50 01 00 00 e8 b8 cd 10 00 48 8b 85 48 ff ff ff 48 c1 e8 03 48 89 c2 48 b8 00 00 00 00 00 fc ff df <80> 3c 02 00 0f 85 8a 01 00 00 49 8b 74 24 08 bf 40 42 0f 00 48 89 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) RSP: 0018:ffff888093d0fe58 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 1ffff110127a1fcd RCX: ffffffff8162e915 RDX: 00000fff820fb94b RSI: ffffffff8162e928 RDI: 0000000000000005 i.e. *(0x00000fff820fb94b + 0xdffffc0000000000 * 1) == 0 *(0xe0000bff820fb94b) == 0 So base == 0x00000fff820fb94b and index == 0xdffffc0000000000 and scale = 1. As scale is 1, base and index might be swapped, but that still does not make any sense. 0xdffffc0000000000 is explicitely loaded into RAX according to the disassembly, but I can't find the corresponding source as this is in the middle of the function prologue and looks KASAN related. RBP: ffff888093d0ff10 R08: ffff8880a8904380 R09: ffff8880a8904c18 R10: fffffbfff1390d30 R11: ffffffff89c86987 R12: 00007ffc107dca50 R13: ffff888093d0fee8 R14: 00007ffc107dca10 R15: 0000000000087a85 FS: 00007f614c01b700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4440cdf000 CR3: 00000000a5236000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? do_sys_settimeofday64+0x250/0x250 ? trace_hardirqs_on_thunk+0x1a/0x1c ? do_syscall_64+0x26/0x760 ? entry_SYSCALL_64_after_hwframe+0x49/0xbe ? do_syscall_64+0x26/0x760 ? lockdep_hardirqs_on+0x421/0x5e0 ? trace_hardirqs_on+0x67/0x240 do_syscall_64+0xfa/0x760 entry_SYSCALL_64_after_hwframe+0x49/0xbe The below is the user code which triggered that: RIP: 0033:0x7f614bb16047 Code: ff ff 73 05 48 83 c4 08 c3 48 8b 0d eb 7d 2e 00 31 d2 48 29 c2 64 89 11 48 83 c8 ff eb e6 90 90 90 90 90 b8 a4 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c1 7d 2e 00 31 d2 48 29 c2 64 23: b8 a4 00 00 00 mov $0xa4,%eax 28: 0f 05 syscall 2a:* 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax 30: 73 01 jae 0x33 32: c3 retq RSP: 002b:00007ffc107dc978 EFLAGS: 00000206 ORIG_RAX: 00000000000000a4 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f614bb16047 RDX: 000000005dcd1ee0 RSI: 00007ffc107dca10 RDI: 00007ffc107dca50 RBP: 0000000000000000 R08: 00007ffc107e6080 R09: 0000000000000eca R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 So RAX is obviously the syscall number and the arguments are in RDI (tv() and RSI (tz), which both look like legit user space addresses. As this is deep in the function prologue compiler/KASAN people might want to have a look at that. Thanks, tglx ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: linux-next boot error: general protection fault in __x64_sys_settimeofday 2019-11-14 12:35 ` Thomas Gleixner @ 2019-11-14 12:42 ` Dmitry Vyukov 2019-11-14 12:43 ` Dmitry Vyukov 2019-11-14 15:02 ` Thomas Gleixner 0 siblings, 2 replies; 10+ messages in thread From: Dmitry Vyukov @ 2019-11-14 12:42 UTC (permalink / raw) To: Thomas Gleixner Cc: syzbot, John Stultz, LKML, sboyd, syzkaller-bugs, the arch/x86 maintainers, kasan-dev, Jann Horn On Thu, Nov 14, 2019 at 1:35 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > On Thu, 14 Nov 2019, syzbot wrote: > > From the full console output: > > kasan: CONFIG_KASAN_INLINE enabled > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: 0000 [#1] PREEMPT SMP KASAN > RIP: 0010:__x64_sys_settimeofday+0x170/0x320 > > Code: 85 50 ff ff ff 85 c0 0f 85 50 01 00 00 e8 b8 cd 10 00 48 8b 85 48 ff ff ff 48 c1 e8 03 48 89 c2 48 b8 00 00 00 00 00 fc ff df <80> 3c 02 00 0f 85 8a 01 00 00 49 8b 74 24 08 bf 40 42 0f 00 48 89 > > 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) > > RSP: 0018:ffff888093d0fe58 EFLAGS: 00010206 > RAX: dffffc0000000000 RBX: 1ffff110127a1fcd RCX: ffffffff8162e915 > RDX: 00000fff820fb94b RSI: ffffffff8162e928 RDI: 0000000000000005 > > i.e. > > *(0x00000fff820fb94b + 0xdffffc0000000000 * 1) == 0 > > *(0xe0000bff820fb94b) == 0 > > So base == 0x00000fff820fb94b and index == 0xdffffc0000000000 and scale = > 1. As scale is 1, base and index might be swapped, but that still does not > make any sense. > > 0xdffffc0000000000 is explicitely loaded into RAX according to the > disassembly, but I can't find the corresponding source as this is in the > middle of the function prologue and looks KASAN related. > > RBP: ffff888093d0ff10 R08: ffff8880a8904380 R09: ffff8880a8904c18 > R10: fffffbfff1390d30 R11: ffffffff89c86987 R12: 00007ffc107dca50 > R13: ffff888093d0fee8 R14: 00007ffc107dca10 R15: 0000000000087a85 > FS: 00007f614c01b700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007f4440cdf000 CR3: 00000000a5236000 CR4: 00000000001406f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > ? do_sys_settimeofday64+0x250/0x250 > ? trace_hardirqs_on_thunk+0x1a/0x1c > ? do_syscall_64+0x26/0x760 > ? entry_SYSCALL_64_after_hwframe+0x49/0xbe > ? do_syscall_64+0x26/0x760 > ? lockdep_hardirqs_on+0x421/0x5e0 > ? trace_hardirqs_on+0x67/0x240 > do_syscall_64+0xfa/0x760 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > The below is the user code which triggered that: > > RIP: 0033:0x7f614bb16047 > > Code: ff ff 73 05 48 83 c4 08 c3 48 8b 0d eb 7d 2e 00 31 d2 48 29 c2 64 89 11 48 83 c8 ff eb e6 90 90 90 90 90 b8 a4 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c1 7d 2e 00 31 d2 48 29 c2 64 > > 23: b8 a4 00 00 00 mov $0xa4,%eax > 28: 0f 05 syscall > 2a:* 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax > 30: 73 01 jae 0x33 > 32: c3 retq > > RSP: 002b:00007ffc107dc978 EFLAGS: 00000206 ORIG_RAX: 00000000000000a4 > RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f614bb16047 > RDX: 000000005dcd1ee0 RSI: 00007ffc107dca10 RDI: 00007ffc107dca50 > RBP: 0000000000000000 R08: 00007ffc107e6080 R09: 0000000000000eca > R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000 > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > So RAX is obviously the syscall number and the arguments are in RDI (tv() > and RSI (tz), which both look like legit user space addresses. > > As this is deep in the function prologue compiler/KASAN people might want > to have a look at that. Looks like a plain user memory access: SYSCALL_DEFINE2(settimeofday, struct __kernel_old_timeval __user *, tv, struct timezone __user *, tz) { .... if (tv->tv_usec > USEC_PER_SEC) // <==== HERE return -EINVAL; Urgently need +Jann's patch to better explain these things! ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: linux-next boot error: general protection fault in __x64_sys_settimeofday 2019-11-14 12:42 ` Dmitry Vyukov @ 2019-11-14 12:43 ` Dmitry Vyukov 2019-11-14 13:22 ` Arnd Bergmann 2019-11-14 15:02 ` Thomas Gleixner 1 sibling, 1 reply; 10+ messages in thread From: Dmitry Vyukov @ 2019-11-14 12:43 UTC (permalink / raw) To: Thomas Gleixner, Arnd Bergmann Cc: syzbot, John Stultz, LKML, sboyd, syzkaller-bugs, the arch/x86 maintainers, kasan-dev, Jann Horn On Thu, Nov 14, 2019 at 1:42 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Thu, Nov 14, 2019 at 1:35 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > > > On Thu, 14 Nov 2019, syzbot wrote: > > > > From the full console output: > > > > kasan: CONFIG_KASAN_INLINE enabled > > kasan: GPF could be caused by NULL-ptr deref or user memory access > > general protection fault: 0000 [#1] PREEMPT SMP KASAN > > RIP: 0010:__x64_sys_settimeofday+0x170/0x320 > > > > Code: 85 50 ff ff ff 85 c0 0f 85 50 01 00 00 e8 b8 cd 10 00 48 8b 85 48 ff ff ff 48 c1 e8 03 48 89 c2 48 b8 00 00 00 00 00 fc ff df <80> 3c 02 00 0f 85 8a 01 00 00 49 8b 74 24 08 bf 40 42 0f 00 48 89 > > > > 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) > > > > RSP: 0018:ffff888093d0fe58 EFLAGS: 00010206 > > RAX: dffffc0000000000 RBX: 1ffff110127a1fcd RCX: ffffffff8162e915 > > RDX: 00000fff820fb94b RSI: ffffffff8162e928 RDI: 0000000000000005 > > > > i.e. > > > > *(0x00000fff820fb94b + 0xdffffc0000000000 * 1) == 0 > > > > *(0xe0000bff820fb94b) == 0 > > > > So base == 0x00000fff820fb94b and index == 0xdffffc0000000000 and scale = > > 1. As scale is 1, base and index might be swapped, but that still does not > > make any sense. > > > > 0xdffffc0000000000 is explicitely loaded into RAX according to the > > disassembly, but I can't find the corresponding source as this is in the > > middle of the function prologue and looks KASAN related. > > > > RBP: ffff888093d0ff10 R08: ffff8880a8904380 R09: ffff8880a8904c18 > > R10: fffffbfff1390d30 R11: ffffffff89c86987 R12: 00007ffc107dca50 > > R13: ffff888093d0fee8 R14: 00007ffc107dca10 R15: 0000000000087a85 > > FS: 00007f614c01b700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: 00007f4440cdf000 CR3: 00000000a5236000 CR4: 00000000001406f0 > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > Call Trace: > > ? do_sys_settimeofday64+0x250/0x250 > > ? trace_hardirqs_on_thunk+0x1a/0x1c > > ? do_syscall_64+0x26/0x760 > > ? entry_SYSCALL_64_after_hwframe+0x49/0xbe > > ? do_syscall_64+0x26/0x760 > > ? lockdep_hardirqs_on+0x421/0x5e0 > > ? trace_hardirqs_on+0x67/0x240 > > do_syscall_64+0xfa/0x760 > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > > > The below is the user code which triggered that: > > > > RIP: 0033:0x7f614bb16047 > > > > Code: ff ff 73 05 48 83 c4 08 c3 48 8b 0d eb 7d 2e 00 31 d2 48 29 c2 64 89 11 48 83 c8 ff eb e6 90 90 90 90 90 b8 a4 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c1 7d 2e 00 31 d2 48 29 c2 64 > > > > 23: b8 a4 00 00 00 mov $0xa4,%eax > > 28: 0f 05 syscall > > 2a:* 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax > > 30: 73 01 jae 0x33 > > 32: c3 retq > > > > RSP: 002b:00007ffc107dc978 EFLAGS: 00000206 ORIG_RAX: 00000000000000a4 > > RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f614bb16047 > > RDX: 000000005dcd1ee0 RSI: 00007ffc107dca10 RDI: 00007ffc107dca50 > > RBP: 0000000000000000 R08: 00007ffc107e6080 R09: 0000000000000eca > > R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000 > > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > > > So RAX is obviously the syscall number and the arguments are in RDI (tv() > > and RSI (tz), which both look like legit user space addresses. > > > > As this is deep in the function prologue compiler/KASAN people might want > > to have a look at that. > > Looks like a plain user memory access: > > SYSCALL_DEFINE2(settimeofday, struct __kernel_old_timeval __user *, tv, > struct timezone __user *, tz) > { > .... > if (tv->tv_usec > USEC_PER_SEC) // <==== HERE > return -EINVAL; > > Urgently need +Jann's patch to better explain these things! +Arnd, this does not look right: commit adde74306a4b05c04dc51f31a08240faf6e97aa9 Author: Arnd Bergmann <arnd@arndb.de> Date: Wed Aug 15 20:04:11 2018 +0200 y2038: time: avoid timespec usage in settimeofday() ... - if (!timeval_valid(&user_tv)) + if (tv->tv_usec > USEC_PER_SEC) return -EINVAL; ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: linux-next boot error: general protection fault in __x64_sys_settimeofday 2019-11-14 12:43 ` Dmitry Vyukov @ 2019-11-14 13:22 ` Arnd Bergmann 2019-11-14 13:28 ` Dmitry Vyukov 0 siblings, 1 reply; 10+ messages in thread From: Arnd Bergmann @ 2019-11-14 13:22 UTC (permalink / raw) To: Dmitry Vyukov Cc: Thomas Gleixner, syzbot, John Stultz, LKML, Stephen Boyd, syzkaller-bugs, the arch/x86 maintainers, kasan-dev, Jann Horn On Thu, Nov 14, 2019 at 1:43 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Thu, Nov 14, 2019 at 1:42 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > On Thu, Nov 14, 2019 at 1:35 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > > > > > On Thu, 14 Nov 2019, syzbot wrote: > > > > > > From the full console output: > > > > Urgently need +Jann's patch to better explain these things! > > +Arnd, this does not look right: > > commit adde74306a4b05c04dc51f31a08240faf6e97aa9 > Author: Arnd Bergmann <arnd@arndb.de> > Date: Wed Aug 15 20:04:11 2018 +0200 > > y2038: time: avoid timespec usage in settimeofday() > ... > > - if (!timeval_valid(&user_tv)) > + if (tv->tv_usec > USEC_PER_SEC) > return -EINVAL; Thanks for the report! I was checking the wrong variable, fixed now, should push it out to my y2038 branch in a bit. Arnd ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: linux-next boot error: general protection fault in __x64_sys_settimeofday 2019-11-14 13:22 ` Arnd Bergmann @ 2019-11-14 13:28 ` Dmitry Vyukov 2019-11-14 13:37 ` Arnd Bergmann 0 siblings, 1 reply; 10+ messages in thread From: Dmitry Vyukov @ 2019-11-14 13:28 UTC (permalink / raw) To: Arnd Bergmann Cc: Thomas Gleixner, syzbot, John Stultz, LKML, Stephen Boyd, syzkaller-bugs, the arch/x86 maintainers, kasan-dev, Jann Horn On Thu, Nov 14, 2019 at 2:22 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Thu, Nov 14, 2019 at 1:43 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > On Thu, Nov 14, 2019 at 1:42 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > > > On Thu, Nov 14, 2019 at 1:35 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > > > > > > > On Thu, 14 Nov 2019, syzbot wrote: > > > > > > > > From the full console output: > > > > > > > Urgently need +Jann's patch to better explain these things! > > > > +Arnd, this does not look right: > > > > commit adde74306a4b05c04dc51f31a08240faf6e97aa9 > > Author: Arnd Bergmann <arnd@arndb.de> > > Date: Wed Aug 15 20:04:11 2018 +0200 > > > > y2038: time: avoid timespec usage in settimeofday() > > ... > > > > - if (!timeval_valid(&user_tv)) > > + if (tv->tv_usec > USEC_PER_SEC) > > return -EINVAL; > > Thanks for the report! > > I was checking the wrong variable, fixed now, > should push it out to my y2038 branch in a bit. > > Arnd This part from the original reporter was lost along the way: IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+dccce9b26ba09ca49966@syzkaller.appspotmail.com https://github.com/google/syzkaller/blob/master/docs/syzbot.md#rebuilt-treesamended-patches ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: linux-next boot error: general protection fault in __x64_sys_settimeofday 2019-11-14 13:28 ` Dmitry Vyukov @ 2019-11-14 13:37 ` Arnd Bergmann 2019-11-14 13:39 ` Dmitry Vyukov 0 siblings, 1 reply; 10+ messages in thread From: Arnd Bergmann @ 2019-11-14 13:37 UTC (permalink / raw) To: Dmitry Vyukov Cc: Thomas Gleixner, syzbot, John Stultz, LKML, Stephen Boyd, syzkaller-bugs, the arch/x86 maintainers, kasan-dev, Jann Horn On Thu, Nov 14, 2019 at 2:28 PM Dmitry Vyukov <dvyukov@google.com> wrote: > On Thu, Nov 14, 2019 at 2:22 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Thu, Nov 14, 2019 at 1:43 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > On Thu, Nov 14, 2019 at 1:42 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > On Thu, Nov 14, 2019 at 1:35 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > > > > > > > > > On Thu, 14 Nov 2019, syzbot wrote: > > > > > > > > > > From the full console output: > > > > > > > > > > Urgently need +Jann's patch to better explain these things! > > > > > > +Arnd, this does not look right: > > > > > > commit adde74306a4b05c04dc51f31a08240faf6e97aa9 > > > Author: Arnd Bergmann <arnd@arndb.de> > > > Date: Wed Aug 15 20:04:11 2018 +0200 > > > > > > y2038: time: avoid timespec usage in settimeofday() > > > ... > > > > > > - if (!timeval_valid(&user_tv)) > > > + if (tv->tv_usec > USEC_PER_SEC) > > > return -EINVAL; > > > > Thanks for the report! > > > > I was checking the wrong variable, fixed now, > > should push it out to my y2038 branch in a bit. > > > > Arnd > > > This part from the original reporter was lost along the way: > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+dccce9b26ba09ca49966@syzkaller.appspotmail.com > > https://github.com/google/syzkaller/blob/master/docs/syzbot.md#rebuilt-treesamended-patches Is there a recommended way to give credit to sysbot if the bug only existed briefly in linux-next? Simply listing Reported-by would be wrong when I fold the fix into my patch, and it also doesn't seem right to leave it as a separate patch while I'm still rebasing the branch. Arnd ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: linux-next boot error: general protection fault in __x64_sys_settimeofday 2019-11-14 13:37 ` Arnd Bergmann @ 2019-11-14 13:39 ` Dmitry Vyukov 2019-11-14 13:51 ` Arnd Bergmann 0 siblings, 1 reply; 10+ messages in thread From: Dmitry Vyukov @ 2019-11-14 13:39 UTC (permalink / raw) To: Arnd Bergmann Cc: Thomas Gleixner, syzbot, John Stultz, LKML, Stephen Boyd, syzkaller-bugs, the arch/x86 maintainers, kasan-dev, Jann Horn On Thu, Nov 14, 2019 at 2:38 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Thu, Nov 14, 2019 at 2:28 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Thu, Nov 14, 2019 at 2:22 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > On Thu, Nov 14, 2019 at 1:43 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > On Thu, Nov 14, 2019 at 1:42 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > > On Thu, Nov 14, 2019 at 1:35 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > > > > > > > > > > > On Thu, 14 Nov 2019, syzbot wrote: > > > > > > > > > > > > From the full console output: > > > > > > > > > > > > > Urgently need +Jann's patch to better explain these things! > > > > > > > > +Arnd, this does not look right: > > > > > > > > commit adde74306a4b05c04dc51f31a08240faf6e97aa9 > > > > Author: Arnd Bergmann <arnd@arndb.de> > > > > Date: Wed Aug 15 20:04:11 2018 +0200 > > > > > > > > y2038: time: avoid timespec usage in settimeofday() > > > > ... > > > > > > > > - if (!timeval_valid(&user_tv)) > > > > + if (tv->tv_usec > USEC_PER_SEC) > > > > return -EINVAL; > > > > > > Thanks for the report! > > > > > > I was checking the wrong variable, fixed now, > > > should push it out to my y2038 branch in a bit. > > > > > > Arnd > > > > > > This part from the original reporter was lost along the way: > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+dccce9b26ba09ca49966@syzkaller.appspotmail.com > > > > https://github.com/google/syzkaller/blob/master/docs/syzbot.md#rebuilt-treesamended-patches /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ this > Is there a recommended way to give credit to sysbot if the bug only > existed briefly in linux-next? Simply listing Reported-by would be wrong > when I fold the fix into my patch, and it also doesn't seem right to > leave it as a separate patch while I'm still rebasing the branch. > > Arnd ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: linux-next boot error: general protection fault in __x64_sys_settimeofday 2019-11-14 13:39 ` Dmitry Vyukov @ 2019-11-14 13:51 ` Arnd Bergmann 0 siblings, 0 replies; 10+ messages in thread From: Arnd Bergmann @ 2019-11-14 13:51 UTC (permalink / raw) To: Dmitry Vyukov Cc: Thomas Gleixner, syzbot, John Stultz, LKML, Stephen Boyd, syzkaller-bugs, the arch/x86 maintainers, kasan-dev, Jann Horn On Thu, Nov 14, 2019 at 2:39 PM Dmitry Vyukov <dvyukov@google.com> wrote: > On Thu, Nov 14, 2019 at 2:38 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Thu, Nov 14, 2019 at 2:28 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > On Thu, Nov 14, 2019 at 2:22 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > > On Thu, Nov 14, 2019 at 1:43 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > > On Thu, Nov 14, 2019 at 1:42 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > > > On Thu, Nov 14, 2019 at 1:35 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > > > > > > > > > > > > > On Thu, 14 Nov 2019, syzbot wrote: > > > > > > > > > > > > > > From the full console output: > > > > > > > > > > > > > > > > Urgently need +Jann's patch to better explain these things! > > > > > > > > > > +Arnd, this does not look right: > > > > > > > > > > commit adde74306a4b05c04dc51f31a08240faf6e97aa9 > > > > > Author: Arnd Bergmann <arnd@arndb.de> > > > > > Date: Wed Aug 15 20:04:11 2018 +0200 > > > > > > > > > > y2038: time: avoid timespec usage in settimeofday() > > > > > ... > > > > > > > > > > - if (!timeval_valid(&user_tv)) > > > > > + if (tv->tv_usec > USEC_PER_SEC) > > > > > return -EINVAL; > > > > > > > > Thanks for the report! > > > > > > > > I was checking the wrong variable, fixed now, > > > > should push it out to my y2038 branch in a bit. > > > > > > > > Arnd > > > > > > > > > This part from the original reporter was lost along the way: > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > Reported-by: syzbot+dccce9b26ba09ca49966@syzkaller.appspotmail.com > > > > > > https://github.com/google/syzkaller/blob/master/docs/syzbot.md#rebuilt-treesamended-patches > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > this Ok, got it. Now pushed out with a Tested-by: syzbot+dccce9b26ba09ca49966@syzkaller.appspotmail.com Arnd ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: linux-next boot error: general protection fault in __x64_sys_settimeofday 2019-11-14 12:42 ` Dmitry Vyukov 2019-11-14 12:43 ` Dmitry Vyukov @ 2019-11-14 15:02 ` Thomas Gleixner 1 sibling, 0 replies; 10+ messages in thread From: Thomas Gleixner @ 2019-11-14 15:02 UTC (permalink / raw) To: Dmitry Vyukov Cc: syzbot, John Stultz, LKML, sboyd, syzkaller-bugs, the arch/x86 maintainers, kasan-dev, Jann Horn On Thu, 14 Nov 2019, Dmitry Vyukov wrote: > On Thu, Nov 14, 2019 at 1:35 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > Looks like a plain user memory access: > > SYSCALL_DEFINE2(settimeofday, struct __kernel_old_timeval __user *, tv, > struct timezone __user *, tz) > { > .... > if (tv->tv_usec > USEC_PER_SEC) // <==== HERE > return -EINVAL; Bah, I looked at a stale next .... ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-11-14 15:02 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-14 10:55 linux-next boot error: general protection fault in __x64_sys_settimeofday syzbot 2019-11-14 12:35 ` Thomas Gleixner 2019-11-14 12:42 ` Dmitry Vyukov 2019-11-14 12:43 ` Dmitry Vyukov 2019-11-14 13:22 ` Arnd Bergmann 2019-11-14 13:28 ` Dmitry Vyukov 2019-11-14 13:37 ` Arnd Bergmann 2019-11-14 13:39 ` Dmitry Vyukov 2019-11-14 13:51 ` Arnd Bergmann 2019-11-14 15:02 ` Thomas Gleixner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).