linux-kernel - Re: kasan behavior when built with unsupported compiler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 9 Mar 2017 12:46:01 +0300
From:   Andrey Ryabinin <aryabinin@...tuozzo.com>
To:     Nikolay Borisov <n.borisov.lkml@...il.com>,
        Dmitry Vyukov <dvyukov@...gle.com>
CC:     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 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.


> 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. 
> 
> 
>