linux-kernel - Re: Use-after-scope Read in tick_sched

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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Wed, 2 May 2018 14:30:17 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Dongsong Yu <yudongsong1992@...il.com>
cc:     Frederic Weisbecker <fweisbec@...il.com>,
        Ingo Molnar <mingo@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, syzkaller@...glegroups.com,
        Will Deacon <will.deacon@....com>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: Use-after-scope Read in tick_sched_handle' bug.

On Wed, 2 May 2018, Dongsong Yu wrote:

CC+ ARM64 folks which should have been cc'ed in the first place.

> Hi,
> I've got the following bug report while fuzzing linux kenrel (4.16.0) on
> arm64 with syzkaller.
> The kernel config file and poc generated by C reproducer are attached.
> 
> Syzkaller hit 'KASAN: use-after-scope Read in tick_sched_handle' bug.
> 
> 
> ==================================================================
> BUG: KASAN: use-after-scope in tick_sched_handle.isra.5+0x64/0xa8
> kernel/time/tick-sched.c:162
> Read of size 8 at addr ffff800073866578 by task syzkaller195252/1474
> 
> CPU: 0 PID: 1474 Comm: syzkaller195252 Not tainted 4.16.0 #2
> Hardware name: linux,dummy-virt (DT)
> Call trace:
>  dump_backtrace+0x0/0x350 arch/arm64/kernel/time.c:64
>  show_stack+0x20/0x30 arch/arm64/kernel/traps.c:151
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x11c/0x198 lib/dump_stack.c:53
>  print_address_description+0x60/0x270 mm/kasan/report.c:256
>  kasan_report_error mm/kasan/report.c:354 [inline]
>  kasan_report+0x248/0x348 mm/kasan/report.c:412
>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>  __asan_load8+0x84/0xa8 mm/kasan/kasan.c:698
>  tick_sched_handle.isra.5+0x64/0xa8 kernel/time/tick-sched.c:162

So on 4.16.0 this is:

   139	static void tick_sched_handle(struct tick_sched *ts, struct pt_regs *regs)
   140	{
   141	#ifdef CONFIG_NO_HZ_COMMON
   142		/*
   143		 * When we are idle and the tick is stopped, we have to touch
   144		 * the watchdog as we might not schedule for a really long
   145		 * time. This happens on complete idle SMP systems while
   146		 * waiting on the login prompt. We also increment the "start of
   147		 * idle" jiffy stamp so the idle accounting adjustment we do
   148		 * when we go busy again does not account too much ticks.
   149		 */
   150		if (ts->tick_stopped) {
   151			touch_softlockup_watchdog_sched();
   152			if (is_idle_task(current))
   153				ts->idle_jiffies++;
   154			/*
   155			 * In case the current tick fired too early past its expected
   156			 * expiration, make sure we don't bypass the next clock reprogramming
   157			 * to the same deadline.
   158			 */
   159			ts->next_tick = 0;
   160		}
   161	#endif
   162		update_process_times(user_mode(regs));

   		^^^^^^^^^^^^^^^^^^

   163		profile_tick(CPU_PROFILING);
   164	}
   165	#endif

Confused to be honest.

>  tick_sched_timer+0x50/0xe0 kernel/time/tick-sched.c:1194
>  __run_hrtimer kernel/time/hrtimer.c:1349 [inline]
>  __hrtimer_run_queues+0x1dc/0x2c0 kernel/time/hrtimer.c:1411
>  hrtimer_interrupt+0x180/0x390 kernel/time/hrtimer.c:1469
>  timer_handler drivers/clocksource/arm_arch_timer.c:588 [inline]
>  arch_timer_handler_virt+0x44/0x70 drivers/clocksource/arm_arch_timer.c:599
>  handle_percpu_devid_irq+0xdc/0x1e8 kernel/irq/chip.c:896
>  generic_handle_irq_desc include/linux/irqdesc.h:159 [inline]
>  generic_handle_irq+0x48/0x68 kernel/irq/irqdesc.c:606
>  __handle_domain_irq+0x8c/0x108 kernel/irq/irqdesc.c:643
>  handle_domain_irq include/linux/irqdesc.h:177 [inline]
>  gic_handle_irq+0x6c/0xd8 drivers/irqchip/irq-gic.c:367
>  el1_irq+0xb0/0x128 arch/arm64/kernel/entry.S:602
>  prep_new_page mm/page_alloc.c:1816 [inline]
>  get_page_from_freelist+0x628/0x1998 mm/page_alloc.c:3239
>  __alloc_pages_nodemask+0x244/0x1600 mm/page_alloc.c:4245
>  alloc_pages_current+0x128/0x1f0 mm/mempolicy.c:2055
>  alloc_pages include/linux/gfp.h:492 [inline]
>  pte_alloc_one arch/arm64/include/asm/pgalloc.h:104 [inline]
>  __pte_alloc+0x8c/0x200 mm/memory.c:654
>  do_anonymous_page+0x844/0x9b0 mm/memory.c:3141
>  handle_pte_fault mm/memory.c:3977 [inline]
>  __handle_mm_fault+0xb94/0x1528 mm/memory.c:4103
>  handle_mm_fault+0x288/0x3e0 mm/memory.c:4140
>  __do_page_fault arch/arm64/mm/fault.c:377 [inline]
>  do_page_fault+0x398/0x630 arch/arm64/mm/fault.c:459
>  do_translation_fault+0x90/0xb0 arch/arm64/mm/fault.c:561
>  do_mem_abort+0xbc/0x208 arch/arm64/mm/fault.c:698
>  el0_da+0x20/0x24
> 
> The buggy address belongs to the page:
> page:ffff7e0001ce1980 count:0 mapcount:0 mapping:0000000000000000 index:0x0
> flags: 0x4fffc00000000000()
> raw: 4fffc00000000000 0000000000000000 0000000000000000 00000000ffffffff
> raw: ffff7e0001ce19a0 ffff7e0001ce19a0 0000000000000000 0000000000000000
> page dumped because: kasan: bad access detected
> 
> Memory state around the buggy address:
>  ffff800073866400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  ffff800073866480: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> >ffff800073866500: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>                                                                 ^
>  ffff800073866580: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>  ffff800073866600: f8 f8 f8 f8 f8 f8 00 00 00 00 00 00 00 00 00 00
> ==================================================================
>