Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753527AbdCIJro (ORCPT ); Thu, 9 Mar 2017 04:47:44 -0500 Received: from mail-ua0-f182.google.com ([209.85.217.182]:34653 "EHLO mail-ua0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752458AbdCIJrk (ORCPT ); Thu, 9 Mar 2017 04:47:40 -0500 MIME-Version: 1.0 In-Reply-To: <95bc2575-b62b-73e5-2324-d02289d92867@virtuozzo.com> References: <1eb0b1ba-3847-9bdc-8f4a-adcd34de3486@gmail.com> <9ebf6262-fd9e-5b58-4039-b0004623493a@gmail.com> <95bc2575-b62b-73e5-2324-d02289d92867@virtuozzo.com> From: Dmitry Vyukov Date: Thu, 9 Mar 2017 10:47:11 +0100 Message-ID: Subject: Re: kasan behavior when built with unsupported compiler To: Andrey Ryabinin Cc: Nikolay Borisov , Alexander Potapenko , LKML , kasan-dev 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: 1954 Lines: 38 On Thu, Mar 9, 2017 at 10:46 AM, Andrey Ryabinin wrote: > On 03/08/2017 11:10 AM, Nikolay Borisov wrote: > >> >> 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 > > As I said before, this is *not* use-after-free. It's out-of-bounds access. > No, kasan is not confused, it doesn't think that object is freed. > Object is allocated and kasan see it as allocated object. > The problem is that filldir reads past the end of that allocated object. > > I don't see any sign that it's a false-positive. Then the question is: why is not it detected with newer compiler? It's equally strange: all of kmalloc/free/copy_to_user have manual instrumentation.