linux-kernel - Re: time: hang due to timer_create/timer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 21 Apr 2017 18:21:25 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andrey Konovalov <andreyknvl@...gle.com>
cc:     LKML <linux-kernel@...r.kernel.org>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Kostya Serebryany <kcc@...gle.com>,
        syzkaller <syzkaller@...glegroups.com>,
        John Stultz <john.stultz@...aro.org>
Subject: Re: time: hang due to timer_create/timer_settime

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