On Fri, 21 Apr 2017, Thomas Gleixner wrote: > On Fri, 21 Apr 2017, Andrey Konovalov wrote: > > Hi, > > > > I've got the following error report while fuzzing the kernel with syzkaller. > > > > On commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7). > > > > A reproducer and .config are attached. > > > > The program hangs the kernel. > > lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3762 > > __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] > > _raw_spin_lock_irqsave+0xc4/0x110 kernel/locking/spinlock.c:159 > > alarmtimer_fired+0x169/0x7a0 kernel/time/alarmtimer.c:189 > > __run_hrtimer kernel/time/hrtimer.c:1212 [inline] > > __hrtimer_run_queues+0x350/0xe50 kernel/time/hrtimer.c:1276 > > hrtimer_interrupt+0x1ab/0x5c0 kernel/time/hrtimer.c:1310 > > local_apic_timer_interrupt+0x6f/0xe0 arch/x86/kernel/apic/apic.c:937 > > smp_apic_timer_interrupt+0x71/0xa0 arch/x86/kernel/apic/apic.c:961 > > apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:487 > > Right. That lacks the protection which we have in the other posix > timers. I'll have a look.
But what's even more alarming is: (*(uint64_t*)0x20aedfe0 = (uint64_t)0x0); (*(uint64_t*)0x20aedfe8 = (uint64_t)0x989680); (*(uint64_t*)0x20aedff0 = (uint64_t)0x800000077359400); (*(uint64_t*)0x20aedff8 = (uint64_t)0x0); r[11] = execute_syscall(__NR_timer_settime, r[6], 0x0ul, 0x20aedfe0ul, 0x20715fe0ul, 0, 0, 0, 0, 0); 0x20aedfe0 is the itimerspec handed to timer_create(). So its->it_interval.tv_sec = 0; its->it_interval.tv_nsec = 0x989680; its->it_value.tv_sec = 0x800000077359400; its->it_value.tv_nsec = 0; it_value.tv_sec is 1.82795e+10 YEARS into the future. How does that timer fire in the first place? Thanks, tglx