Message-ID: <CACT4Y+Zvjo8yeUMEczd3yZKVsDT8U8NHsyHGUBJjQjbWWiKO-w@mail.gmail.com>
Date:   Wed, 8 Mar 2017 13:34:24 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Nikolay Borisov <n.borisov.lkml@...il.com>
Cc:     Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Alexander Potapenko <glider@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kasan-dev <kasan-dev@...glegroups.com>,
        Kees Cook <keescook@...gle.com>
Subject: Re: kasan behavior when built with unsupported compiler

On Wed, Mar 8, 2017 at 9:10 AM, Nikolay Borisov
<n.borisov.lkml@...il.com> wrote:
>
>
> On  7.03.2017 17:54, Dmitry Vyukov wrote:
>> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
>> <n.borisov.lkml@...il.com> 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.

Powered by blists - more mailing lists