Re: use-after-free in __perf_install_in_context

From: Dmitry Vyukov <dvyukov@google.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	syzkaller <syzkaller@googlegroups.com>,
	Kostya Serebryany <kcc@google.com>,
	Alexander Potapenko <glider@google.com>,
	Eric Dumazet <edumazet@google.com>,
	Sasha Levin <sasha.levin@oracle.com>
Subject: Re: use-after-free in __perf_install_in_context
Date: Tue, 8 Dec 2015 17:12:04 +0100	[thread overview]
Message-ID: <CACT4Y+ZsKVN+FXjyRNYgtWxMjjYfB9uz8f0QAW7iGjLE5GCQBA@mail.gmail.com> (raw)
In-Reply-To: <20151208032405.GA47397@ast-mbp.thefacebook.com>

On Tue, Dec 8, 2015 at 4:24 AM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Mon, Dec 07, 2015 at 05:09:21PM +0100, Dmitry Vyukov wrote:
>> > 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
>
> I was hacking something similar to categorize stack traces with u32 id.
> How are you planning to limit the number of such stack traces ?
> and what is the interface for user space to get stack trace from an id?

We don't limit number of stack traces. Kernel does not seem to use
data-driven recursion extensively, so there is limited number of
stacks. Though, probably we will need to strip non-interrupt part for
interrupt stacks, otherwise that can produce unbounded number of
different stacks.
There is no interface for user-space, it is used only inside of kernel
to save stacks for memory blocks (rcu callbacks, thread pool items in
the future).
The design is based on what we successfully and extensively use in
user-space sanitizers for years. Current code is here:
https://github.com/ramosian-glider/kasan/commit/fb0eefd212366401ed5ad244233ef379a27bfb46