linux-next boot error: general protection fault in __x64_sys_settimeofday

linux-next boot error: general protection fault in __x64_sys_settimeofday

[syzbot]

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.

Re: linux-next boot error: general protection fault in __x64_sys_settimeofday

[Thomas Gleixner]

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

Re: linux-next boot error: general protection fault in __x64_sys_settimeofday

[Dmitry Vyukov]

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!

Re: linux-next boot error: general protection fault in __x64_sys_settimeofday

[Dmitry Vyukov]

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;

Re: linux-next boot error: general protection fault in __x64_sys_settimeofday

[Arnd Bergmann]

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

Re: linux-next boot error: general protection fault in __x64_sys_settimeofday

[Dmitry Vyukov]

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

Re: linux-next boot error: general protection fault in __x64_sys_settimeofday

[Arnd Bergmann]

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

Re: linux-next boot error: general protection fault in __x64_sys_settimeofday

[Dmitry Vyukov]

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

Re: linux-next boot error: general protection fault in __x64_sys_settimeofday

[Arnd Bergmann]

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

Re: linux-next boot error: general protection fault in __x64_sys_settimeofday

[Thomas Gleixner]

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 ....