Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933530AbcKOU4R (ORCPT ); Tue, 15 Nov 2016 15:56:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33584 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932333AbcKOU4P (ORCPT ); Tue, 15 Nov 2016 15:56:15 -0500 Date: Tue, 15 Nov 2016 14:56:13 -0600 From: Josh Poimboeuf To: Dmitry Vyukov Cc: Peter Zijlstra , Vince Weaver , "linux-kernel@vger.kernel.org" , Ingo Molnar , Arnaldo Carvalho de Melo , "davej@codemonkey.org.uk" , Stephane Eranian Subject: Re: perf: fuzzer KASAN unwind_get_return_address Message-ID: <20161115205613.mi5qjfs6ty22e34s@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.28]); Tue, 15 Nov 2016 20:56:15 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2334 Lines: 41 On Tue, Nov 15, 2016 at 11:04:45AM -0800, Dmitry Vyukov wrote: > 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. I'm not so sure about that. The unwind should be precise here: it should only be looking at the frame pointers and return addresses on the current task's stack. I can't see any reason why it would be reading into the KASAN stack redzone. -- Josh