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@xxxxxxxxxx> wrote:
>
> On Thu, Nov 14, 2019 at 1:35 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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@xxxxxxxx>
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;