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 10:47:11 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Andrey Ryabinin <aryabinin@...tuozzo.com>
Cc:     Nikolay Borisov <n.borisov.lkml@...il.com>,
        Alexander Potapenko <glider@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kasan-dev <kasan-dev@...glegroups.com>
Subject: Re: kasan behavior when built with unsupported compiler

On Thu, Mar 9, 2017 at 10:46 AM, Andrey Ryabinin
<aryabinin@...tuozzo.com> 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.