Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932892AbcKOTFJ (ORCPT ); Tue, 15 Nov 2016 14:05:09 -0500 Received: from mail-qt0-f171.google.com ([209.85.216.171]:34311 "EHLO mail-qt0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751359AbcKOTFH (ORCPT ); Tue, 15 Nov 2016 14:05:07 -0500 MIME-Version: 1.0 In-Reply-To: <20161115185756.GL3142@twins.programming.kicks-ass.net> References: <20161115185756.GL3142@twins.programming.kicks-ass.net> From: Dmitry Vyukov Date: Tue, 15 Nov 2016 11:04:45 -0800 Message-ID: Subject: Re: perf: fuzzer KASAN unwind_get_return_address To: Peter Zijlstra Cc: Vince Weaver , "linux-kernel@vger.kernel.org" , Ingo Molnar , Arnaldo Carvalho de Melo , "davej@codemonkey.org.uk" , Stephane Eranian , jpoimboe@redhat.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1956 Lines: 32 On Tue, Nov 15, 2016 at 10:57 AM, 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? I think this is a false positive due to imprecise unwind that hits a stack redzone. We probably need to use READ_ONCE_NOCHECK as in get_wchan.