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]
Message-ID: <95bc2575-b62b-73e5-2324-d02289d92867@virtuozzo.com>
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. 
> 
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ