Re: use-after-free in __perf_install_in_context

From: Dmitry Vyukov
Date: Mon Dec 07 2015 - 11:09:48 EST


On Mon, Dec 7, 2015 at 4:36 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> On Fri, Dec 04, 2015 at 09:04:35PM +0100, Dmitry Vyukov wrote:
>> ==================================================================
>> BUG: KASAN: use-after-free in __lock_acquire+0x4e99/0x5100 at addr
>> ffff880038706e60
>> Read of size 8 by task syzkaller_execu/6513
>> =============================================================================
>> BUG kmalloc-1024 (Not tainted): kasan: bad access detected
>> -----------------------------------------------------------------------------
>>
>> Disabling lock debugging due to kernel taint
>> INFO: Allocated in alloc_perf_context+0x4c/0x100 age=263 cpu=1 pid=6428
>> [< inline >] kzalloc include/linux/slab.h:602
>> [< none >] alloc_perf_context+0x4c/0x100 kernel/events/core.c:3399
>> [< none >] find_get_context+0x187/0x830 kernel/events/core.c:3506
>> [< none >] SYSC_perf_event_open+0xe50/0x21a0 kernel/events/core.c:8375
>> [< none >] SyS_perf_event_open+0x39/0x50 kernel/events/core.c:8236
>> [< none >] tracesys_phase2+0x88/0x8d arch/x86/entry/entry_64.S:269
>>
>> INFO: Freed in free_ctx+0x4b/0x70 age=174 cpu=2 pid=8105
>> [< none >] kfree+0x26f/0x3e0 mm/slub.c:3632
>> [< none >] free_ctx+0x4b/0x70 kernel/events/core.c:872
>> [< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
>> [< inline >] rcu_do_batch kernel/rcu/tree.c:2693
>> [< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:2961
>> [< inline >] __rcu_process_callbacks kernel/rcu/tree.c:2928
>> [< none >] rcu_process_callbacks+0x631/0x19e0 kernel/rcu/tree.c:2945
>> [< none >] __do_softirq+0x2e5/0xb40 kernel/softirq.c:273
>> [< inline >] invoke_softirq kernel/softirq.c:350
>> [< none >] irq_exit+0x165/0x1e0 kernel/softirq.c:391
>> [< inline >] exiting_irq ./arch/x86/include/asm/apic.h:653
>> [< none >] smp_apic_timer_interrupt+0x88/0xc0
>> arch/x86/kernel/apic/apic.c:926
>> [< none >] apic_timer_interrupt+0x87/0x90
>> arch/x86/entry/entry_64.S:678
>
> So it would be _awesome_ if we could somehow extend this callchain to
> include the site that calls call_rcu().

We have a patch for KASAN in works that adds so-called stack depot
which allows to map a stack trace onto uint32 id. Then we can plumb
these ids not only to memory blocks, but also to rcu callbacks, thread
pool items, etc. But it's not yet ready.
If your audit does not give any results, can you give me a patch that
prints rcu callback submission stacks in KASAN reports?


> In any case, this looks like we got the refcounting wrong some place,
> I'll go audit that stuff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/