lkml.org 
[lkml]   [2017]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: kasan behavior when built with unsupported compiler
    On Wed, Mar 8, 2017 at 9:10 AM, Nikolay Borisov
    <n.borisov.lkml@gmail.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@gmail.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.

    \
     
     \ /
      Last update: 2017-03-08 13:35    [W:3.556 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site