LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re: Use-after-scope Read in tick_sched_handle' bug.
       [not found] <CAD1Xb+9K2dwas-0boF1iOyyVgYfwvCu7UHT37yFUUTHrmRj9QA@mail.gmail.com>
@ 2018-05-02 11:20 ` Dmitry Vyukov
  0 siblings, 0 replies; 2+ messages in thread
From: Dmitry Vyukov @ 2018-05-02 11:20 UTC (permalink / raw)
  To: Dongsong Yu; +Cc: LKML, syzkaller

On Wed, May 2, 2018 at 12:35 PM, Dongsong Yu <yudongsong1992@gmail.com> wrote:
> 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.

Hi Dongsong,

This looks like false positive caused by this gcc bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230



> ==================================================================
> 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
>  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
> ==================================================================
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Use-after-scope Read in tick_sched_handle' bug.
       [not found] <CAD1Xb+9C8f8uXU6G3FMM+q_h+uKq=ed8g4C4Bn2H2vZV693wbg@mail.gmail.com>
@ 2018-05-02 12:30 ` Thomas Gleixner
  0 siblings, 0 replies; 2+ messages in thread
From: Thomas Gleixner @ 2018-05-02 12:30 UTC (permalink / raw)
  To: Dongsong Yu
  Cc: Frederic Weisbecker, Ingo Molnar, LKML, syzkaller, Will Deacon,
	Mark Rutland

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
> ==================================================================
> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-05-02 12:30 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAD1Xb+9K2dwas-0boF1iOyyVgYfwvCu7UHT37yFUUTHrmRj9QA@mail.gmail.com>
2018-05-02 11:20 ` Use-after-scope Read in tick_sched_handle' bug Dmitry Vyukov
     [not found] <CAD1Xb+9C8f8uXU6G3FMM+q_h+uKq=ed8g4C4Bn2H2vZV693wbg@mail.gmail.com>
2018-05-02 12:30 ` Thomas Gleixner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).