Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753786AbcKOTFy (ORCPT ); Tue, 15 Nov 2016 14:05:54 -0500 Received: from mail-it0-f67.google.com ([209.85.214.67]:34418 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753154AbcKOTFx (ORCPT ); Tue, 15 Nov 2016 14:05:53 -0500 From: Vince Weaver X-Google-Original-From: Vince Weaver Date: Tue, 15 Nov 2016 14:05:50 -0500 (EST) X-X-Sender: vince@macbook-air To: Peter Zijlstra cc: Vince Weaver , "linux-kernel@vger.kernel.org" , Ingo Molnar , Arnaldo Carvalho de Melo , "davej@codemonkey.org.uk" , "dvyukov@google.com" , Stephane Eranian , jpoimboe@redhat.com Subject: Re: perf: fuzzer KASAN unwind_get_return_address In-Reply-To: <20161115185756.GL3142@twins.programming.kicks-ass.net> Message-ID: References: <20161115185756.GL3142@twins.programming.kicks-ass.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2256 Lines: 46 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; }