Messages in this thread | | | From | Dmitry Vyukov <> | Date | Thu, 14 Nov 2019 13:43:37 +0100 | Subject | Re: linux-next boot error: general protection fault in __x64_sys_settimeofday |
| |
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;
| |