Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753055AbdCHMfF (ORCPT ); Wed, 8 Mar 2017 07:35:05 -0500 Received: from mail-ua0-f171.google.com ([209.85.217.171]:32953 "EHLO mail-ua0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752867AbdCHMeq (ORCPT ); Wed, 8 Mar 2017 07:34:46 -0500 MIME-Version: 1.0 In-Reply-To: <9ebf6262-fd9e-5b58-4039-b0004623493a@gmail.com> References: <1eb0b1ba-3847-9bdc-8f4a-adcd34de3486@gmail.com> <9ebf6262-fd9e-5b58-4039-b0004623493a@gmail.com> From: Dmitry Vyukov Date: Wed, 8 Mar 2017 13:34:24 +0100 Message-ID: Subject: Re: kasan behavior when built with unsupported compiler To: Nikolay Borisov Cc: Andrey Ryabinin , Alexander Potapenko , LKML , kasan-dev , Kees Cook 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: 3394 Lines: 71 On Wed, Mar 8, 2017 at 9:10 AM, Nikolay Borisov wrote: > > > On 7.03.2017 17:54, Dmitry Vyukov wrote: >> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov >> wrote: >>> Hello, >>> >>> I've been chasing a particular UAF as reported by kasan >>> (https://www.spinics.net/lists/kernel/msg2458136.html). However, one >>> thing which I took notice of rather lately is that I was building my >>> kernel with gcc 4.7.4 which is not supported by kasan as indicated by >>> the following string: >>> >>> scripts/Makefile.kasan:19: Cannot use CONFIG_KASAN: >>> -fsanitize=kernel-address is not supported by compiler >>> >>> >>> Nevertheless, the kernel compiles and when I boot it I see the kasan >>> splats as per the referenced thread. If, however, I build the kernel >>> with a newer compiler version 5.4.0 kasan no longer complains. >>> >>> >>> At this point I'm wondering whether the splats can be due to old >>> compiler being used e.g. false positives or are they genuine splats and >>> gcc 5 somehow obfuscates them ? Clearly despite the warning about not >>> being able to use CONFIG_KASAN it is still working since I'm seeing the >>> splats. Is this valid behavior ? >> >> >> Hi, >> >> Re the message that kasan is not supported while it's still enabled in the end. >> I think it's an issue related to gcc plugins. Originally kasan was >> supported with 5.0+ thus the message. However, later we extended this >> support to 4.5+ with gcc plugins. However, that confusing message from >> build system was not fixed. So yes, it's confusing and it's something >> to fix, but mostly you can just ignore it. >> >> Re false positives with 4.7. By default I would assume that it is true >> positive. Should be easy to check with manual printfs. > > So apparently this is indeed a false positive, resulting from using the old > compiler. I used the attached patch to verify it. > > And what it prints is : > [ 17.184288] Assigned fbdev-blacklist.conff(ffff880001ea8020)20 whole object: ffff88006ae8fdb0 inode:ffff88006bff60d0 > [ 17.185808] Calling filldir with ffff88006ae8fdb0 > > So the first line essentially happens when the object ffff88006ae8fdb0 is > being allocated and the second when it's used in filldir. The warning in > ext4_ext_map_blocks doesn't trigger. However, if I remove the check for > the value of ext4_global_pointer then I see multiple lines such as: > [ 17.386283] ext4_ext_map_blocks:freeing pointer used in ext4_htree_store_dirent: ffff88006ae8fdb0 inode: ffff88006bff60d0 > [ 17.387601] Assigned fbdev-blacklist.conff(ffff880001eb3020)20 whole object: ffff88006ae8fdb0 inode:ffff88006bff60d0 > [ 17.388740] Calling filldir with ffff88006ae8fdb0 > > so that same object was used right before it is allocated again in > ext4_htree_store_dirent. And when you think about it it is logical since > before filling in the dentry names in ext4_htree_store_dirent ext4 has to fetch the > contents of the directory from disk. > > This leads me to believe that kasan is getting confused thinking that > the object is being freed AFTER being allocated in > ext4_htree_store_dirent but testing shows it's being freed BEFORE. So > I deem this a false positive, triggered by the compiler. I am not following how compiler version can affect any of this. But if you say this is a false positive, let it be so. gcc 4.7 is old.