From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934084AbcKOU5w (ORCPT ); Tue, 15 Nov 2016 15:57:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43490 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932305AbcKOU5u (ORCPT ); Tue, 15 Nov 2016 15:57:50 -0500 Date: Tue, 15 Nov 2016 14:57:48 -0600 From: Josh Poimboeuf To: Vince Weaver Cc: Peter Zijlstra , "linux-kernel@vger.kernel.org" , Ingo Molnar , Arnaldo Carvalho de Melo , "davej@codemonkey.org.uk" , "dvyukov@google.com" , Stephane Eranian Subject: Re: perf: fuzzer KASAN unwind_get_return_address Message-ID: <20161115205748.xtroftp55igs55bz@treble> References: <20161115185756.GL3142@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 15 Nov 2016 20:57:50 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 15, 2016 at 02:05:50PM -0500, Vince Weaver wrote: > On Tue, 15 Nov 2016, Peter Zijlstra wrote: > > > On Tue, Nov 15, 2016 at 12:43:56PM -0500, Vince Weaver wrote: > > > > > > Running on my haswell machine with the imc/uncore patch applied, the > > > perf_fuzzer next tripped over this issue. > > > > > > [ 202.034495] BAD LUCK: lost 371 message(s) from NMI context! > > > [ 202.034496] ================================================================== > > > [ 202.048327] BUG: KASAN: stack-out-of-bounds in unwind_get_return_address+0x35/0x80 at addr ffff8800cff0bd90 > > > [ 202.058826] Read of size 8 by task perf_fuzzer/16254 > > > [ 202.064186] page:ffffea00033fc2c0 count:1 mapcount:0 mapping: (null) index:0x0^Ac > > > [ 202.073068] flags: 0x1ffff8000000400(reserved) > > > [ 202.077885] page dumped because: kasan: bad access detected > > > [ 202.083880] CPU: 4 PID: 16254 Comm: perf_fuzzer Not tainted 4.9.0-rc5+ #5 > > > [ 202.091204] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS 01/26/2014 > > > [ 202.099181] ffff8800cff0b1d8^Ac ffffffff816bb796^Ac ffff8800cff0b270^Ac ffff8800cff0bd90^Ac > > > [ 202.107896] ffff8800cff0b260^Ac ffffffff812fbe95^Ac 00007ffc9d1ab480^Ac 0000000000000000^Ac > > > [ 202.116638] ffffffff8125117d^Ac 0000000000000092^Ac 0000000000000000^Ac ffff8800cff0b7c0^Ac > > > [ 202.125339] Call Trace: > > > [ 202.127994] [] dump_stack+0x63/0x8d > > > [ 202.134184] [] kasan_report_error+0x495/0x4c0 > > > [ 202.140680] [] ? perf_output_begin+0x28d/0x4c0 > > > [ 202.147228] [] kasan_report+0x39/0x40 > > > [ 202.152987] [] ? unwind_get_return_address+0x35/0x80 > > > [ 202.160094] [] __asan_load8+0x5e/0x70 > > > [ 202.165859] [] unwind_get_return_address+0x35/0x80 > > > > Josh, any ideas? > > From what I can tell this maps to: > > unsigned long unwind_get_return_address(struct unwind_state *state) > { > unsigned long addr; > unsigned long *addr_p = unwind_get_return_address_ptr(state); > > if (unwind_done(state)) > return 0; > > >> addr = ftrace_graph_ret_addr(state->task, &state->graph_idx, *addr_p, > addr_p); > > return __kernel_text_address(addr) ? addr : 0; > } Hi Vince, Would you mind posting a disassembly of unwind_get_return_address()? Any idea how recreatable it is? (In particular I'd be interested in seeing this dump with the latest unwinder improvements in the -tip tree, which dump the pt_regs associated with an interrupt.) -- Josh