Re: kasan behavior when built with unsupported compiler

[Andrey Ryabinin]

On 03/09/2017 01:16 PM, Dmitry Vyukov wrote:
> 
> Looking at this report I don't see how this is OOB.
> Object starts at 0x88006a2255e0, object size is 69 bytes (from shadow).
> 88006a22560e + 20 bytes is not OOB.
> 

Indeed, perhaps gcc 4.7.4 miscompiles something check_memory_region ?
That's the only reasonable explanation I have.

Re: kasan behavior when built with unsupported compiler

[Andrey Ryabinin]

On 03/09/2017 01:16 PM, Dmitry Vyukov wrote:
> 
> Looking at this report I don't see how this is OOB.
> Object starts at 0x88006a2255e0, object size is 69 bytes (from shadow).
> 88006a22560e + 20 bytes is not OOB.
> 

Indeed, perhaps gcc 4.7.4 miscompiles something check_memory_region ?
That's the only reasonable explanation I have.

Re: kasan behavior when built with unsupported compiler

[Dmitry Vyukov]

On Thu, Mar 9, 2017 at 10:58 AM, Nikolay Borisov
 wrote:
>
>
> On  9.03.2017 11:46, Andrey Ryabinin 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(880001ea8020)20 whole 
>>> object: 88006ae8fdb0 inode:88006bff60d0
>>> [   17.185808] Calling filldir with 88006ae8fdb0
>>>
>>> So the first line essentially happens when the object 88006ae8fdb0 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: 88006ae8fdb0 inode: 88006bff60d0
>>> [   17.387601] Assigned fbdev-blacklist.conff(880001eb3020)20 whole 
>>> object: 88006ae8fdb0 inode:88006bff60d0
>>> [   17.388740] Calling filldir with 88006ae8fdb0
>>>
>>> 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.
>
> Okay in that case I will continue digging. So the name is indeed housed
> at the end of the struct fname. In ext4_htree_store_dirent this
> structure seems allocated correctly sizeof(struct fname) + ent_name->len
> + 1;
>
> Also the read should indeed be 20 bytes since the filename in question
> fbdev-blacklist.conf is indeed 20 bytes. This implies that the 'namlen'
> passed to copy_to_user is also correct. I guess I will have to look at
> the generated assembly between the 2 gcc versions and see if anything
> pops out.
>
>>
>>
>>> 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.


Looking at this report I don't see how this is OOB.
Object starts at 0x88006a2255e0, object size is 69 bytes (from shadow).
88006a22560e + 20 bytes is not OOB.


BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr 88006a22560e
Read of size 20 by task systemd/1
=
BUG kmalloc-96 (Not tainted): kasan: bad access detected
-

Disabling lock debugging due to kernel taint
INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=0 cpu=2 pid=1
[] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446
[] __slab_alloc+0x4f/0x86 mm/slub.c:2475
[< inline >] slab_alloc_node mm/slub.c:2538
[< inline >] slab_alloc mm/slub.c:2580
[] __kmalloc+0x27a/0x340 mm/slub.c:3561
[< inline >] kmalloc include/linux/slab.h:483
[< inline >] kzalloc include/linux/slab.h:622
[] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447
[] htree_dirblock_to_tree+0x16a/0x190 fs/ext4/namei.c:1001
[] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075
[< inline >] ext4_dx_readdir fs/ext4/dir.c:571
[] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121
[] iterate_dir+0x7d/0x190 fs/readdir.c:50
[< inline >] SYSC_getdents fs/readdir.c:230
[] SyS_getdents+0x91/0x120 fs/readdir.c:212
[] entry_SYSCALL_64_fastpath+0x23/0xc1
arch/x86/entry/entry_64.S:207

INFO: Freed in ext4_ext_map_blocks+0x7f9/0x23e0 age=1 cpu=2 pid=1
[] __slab_free+0x31b/0x440 mm/slub.c:2657
[< inline >] slab_free mm/slub.c:2810
[] kfree+0x27f/0x2d0 mm/slub.c:3662
[] ext4_ext_map_blocks+0x7f9/0x23e0 fs/ext4/extents.c:4619
[] ext4_map_blocks+0x3b4/0x5b0 fs/ext4/inode.c:529
[] ext4_getblk+0x54/0x1a0 fs/ext4/inode.c:929
[] ext4_bread+0x13/0x90 fs/ext4/inode.c:979
[] __ext4_read_dirblock+0x3f/0x380 fs/ext4/namei.c:99
[] htree_dirblock_to_tree+0x48/0x190 fs/ext4/namei.c:959
[] ext4_htree_fill_tree+0xaa/0x310 

Re: kasan behavior when built with unsupported compiler

[Dmitry Vyukov]

On Thu, Mar 9, 2017 at 10:58 AM, Nikolay Borisov
 wrote:
>
>
> On  9.03.2017 11:46, Andrey Ryabinin 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(880001ea8020)20 whole 
>>> object: 88006ae8fdb0 inode:88006bff60d0
>>> [   17.185808] Calling filldir with 88006ae8fdb0
>>>
>>> So the first line essentially happens when the object 88006ae8fdb0 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: 88006ae8fdb0 inode: 88006bff60d0
>>> [   17.387601] Assigned fbdev-blacklist.conff(880001eb3020)20 whole 
>>> object: 88006ae8fdb0 inode:88006bff60d0
>>> [   17.388740] Calling filldir with 88006ae8fdb0
>>>
>>> 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.
>
> Okay in that case I will continue digging. So the name is indeed housed
> at the end of the struct fname. In ext4_htree_store_dirent this
> structure seems allocated correctly sizeof(struct fname) + ent_name->len
> + 1;
>
> Also the read should indeed be 20 bytes since the filename in question
> fbdev-blacklist.conf is indeed 20 bytes. This implies that the 'namlen'
> passed to copy_to_user is also correct. I guess I will have to look at
> the generated assembly between the 2 gcc versions and see if anything
> pops out.
>
>>
>>
>>> 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.


Looking at this report I don't see how this is OOB.
Object starts at 0x88006a2255e0, object size is 69 bytes (from shadow).
88006a22560e + 20 bytes is not OOB.


BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr 88006a22560e
Read of size 20 by task systemd/1
=
BUG kmalloc-96 (Not tainted): kasan: bad access detected
-

Disabling lock debugging due to kernel taint
INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=0 cpu=2 pid=1
[] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446
[] __slab_alloc+0x4f/0x86 mm/slub.c:2475
[< inline >] slab_alloc_node mm/slub.c:2538
[< inline >] slab_alloc mm/slub.c:2580
[] __kmalloc+0x27a/0x340 mm/slub.c:3561
[< inline >] kmalloc include/linux/slab.h:483
[< inline >] kzalloc include/linux/slab.h:622
[] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447
[] htree_dirblock_to_tree+0x16a/0x190 fs/ext4/namei.c:1001
[] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075
[< inline >] ext4_dx_readdir fs/ext4/dir.c:571
[] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121
[] iterate_dir+0x7d/0x190 fs/readdir.c:50
[< inline >] SYSC_getdents fs/readdir.c:230
[] SyS_getdents+0x91/0x120 fs/readdir.c:212
[] entry_SYSCALL_64_fastpath+0x23/0xc1
arch/x86/entry/entry_64.S:207

INFO: Freed in ext4_ext_map_blocks+0x7f9/0x23e0 age=1 cpu=2 pid=1
[] __slab_free+0x31b/0x440 mm/slub.c:2657
[< inline >] slab_free mm/slub.c:2810
[] kfree+0x27f/0x2d0 mm/slub.c:3662
[] ext4_ext_map_blocks+0x7f9/0x23e0 fs/ext4/extents.c:4619
[] ext4_map_blocks+0x3b4/0x5b0 fs/ext4/inode.c:529
[] ext4_getblk+0x54/0x1a0 fs/ext4/inode.c:929
[] ext4_bread+0x13/0x90 fs/ext4/inode.c:979
[] __ext4_read_dirblock+0x3f/0x380 fs/ext4/namei.c:99
[] htree_dirblock_to_tree+0x48/0x190 fs/ext4/namei.c:959
[] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075
[< inline  

Re: kasan behavior when built with unsupported compiler

[Andrey Ryabinin]

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(880001ea8020)20 whole 
> object: 88006ae8fdb0 inode:88006bff60d0
> [   17.185808] Calling filldir with 88006ae8fdb0
> 
> So the first line essentially happens when the object 88006ae8fdb0 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: 88006ae8fdb0 inode: 88006bff60d0
> [   17.387601] Assigned fbdev-blacklist.conff(880001eb3020)20 whole 
> object: 88006ae8fdb0 inode:88006bff60d0
> [   17.388740] Calling filldir with 88006ae8fdb0
> 
> 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. 
> 
> 
> 

Re: kasan behavior when built with unsupported compiler

[Andrey Ryabinin]

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(880001ea8020)20 whole 
> object: 88006ae8fdb0 inode:88006bff60d0
> [   17.185808] Calling filldir with 88006ae8fdb0
> 
> So the first line essentially happens when the object 88006ae8fdb0 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: 88006ae8fdb0 inode: 88006bff60d0
> [   17.387601] Assigned fbdev-blacklist.conff(880001eb3020)20 whole 
> object: 88006ae8fdb0 inode:88006bff60d0
> [   17.388740] Calling filldir with 88006ae8fdb0
> 
> 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. 
> 
> 
> 

Re: kasan behavior when built with unsupported compiler

[Nikolay Borisov]

On  9.03.2017 11:46, Andrey Ryabinin 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(880001ea8020)20 whole 
>> object: 88006ae8fdb0 inode:88006bff60d0
>> [   17.185808] Calling filldir with 88006ae8fdb0
>>
>> So the first line essentially happens when the object 88006ae8fdb0 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: 88006ae8fdb0 inode: 88006bff60d0
>> [   17.387601] Assigned fbdev-blacklist.conff(880001eb3020)20 whole 
>> object: 88006ae8fdb0 inode:88006bff60d0
>> [   17.388740] Calling filldir with 88006ae8fdb0
>>
>> 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.

Okay in that case I will continue digging. So the name is indeed housed
at the end of the struct fname. In ext4_htree_store_dirent this
structure seems allocated correctly sizeof(struct fname) + ent_name->len
+ 1;

Also the read should indeed be 20 bytes since the filename in question
fbdev-blacklist.conf is indeed 20 bytes. This implies that the 'namlen'
passed to copy_to_user is also correct. I guess I will have to look at
the generated assembly between the 2 gcc versions and see if anything
pops out.

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

Re: kasan behavior when built with unsupported compiler

[Nikolay Borisov]

On  9.03.2017 11:46, Andrey Ryabinin 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(880001ea8020)20 whole 
>> object: 88006ae8fdb0 inode:88006bff60d0
>> [   17.185808] Calling filldir with 88006ae8fdb0
>>
>> So the first line essentially happens when the object 88006ae8fdb0 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: 88006ae8fdb0 inode: 88006bff60d0
>> [   17.387601] Assigned fbdev-blacklist.conff(880001eb3020)20 whole 
>> object: 88006ae8fdb0 inode:88006bff60d0
>> [   17.388740] Calling filldir with 88006ae8fdb0
>>
>> 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.

Okay in that case I will continue digging. So the name is indeed housed
at the end of the struct fname. In ext4_htree_store_dirent this
structure seems allocated correctly sizeof(struct fname) + ent_name->len
+ 1;

Also the read should indeed be 20 bytes since the filename in question
fbdev-blacklist.conf is indeed 20 bytes. This implies that the 'namlen'
passed to copy_to_user is also correct. I guess I will have to look at
the generated assembly between the 2 gcc versions and see if anything
pops out.

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

Re: kasan behavior when built with unsupported compiler

[Dmitry Vyukov]

On Thu, Mar 9, 2017 at 10:46 AM, Andrey Ryabinin
 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(880001ea8020)20 whole 
>> object: 88006ae8fdb0 inode:88006bff60d0
>> [   17.185808] Calling filldir with 88006ae8fdb0
>>
>> So the first line essentially happens when the object 88006ae8fdb0 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: 88006ae8fdb0 inode: 88006bff60d0
>> [   17.387601] Assigned fbdev-blacklist.conff(880001eb3020)20 whole 
>> object: 88006ae8fdb0 inode:88006bff60d0
>> [   17.388740] Calling filldir with 88006ae8fdb0
>>
>> 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.

Re: kasan behavior when built with unsupported compiler

[Dmitry Vyukov]

On Thu, Mar 9, 2017 at 10:46 AM, Andrey Ryabinin
 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(880001ea8020)20 whole 
>> object: 88006ae8fdb0 inode:88006bff60d0
>> [   17.185808] Calling filldir with 88006ae8fdb0
>>
>> So the first line essentially happens when the object 88006ae8fdb0 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: 88006ae8fdb0 inode: 88006bff60d0
>> [   17.387601] Assigned fbdev-blacklist.conff(880001eb3020)20 whole 
>> object: 88006ae8fdb0 inode:88006bff60d0
>> [   17.388740] Calling filldir with 88006ae8fdb0
>>
>> 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.

Re: kasan behavior when built with unsupported compiler

[Dmitry Vyukov]

On Wed, Mar 8, 2017 at 9:10 AM, Nikolay Borisov
 wrote:
>
>
> On  7.03.2017 17:54, Dmitry Vyukov wrote:
>> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
>>  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(880001ea8020)20 whole 
> object: 88006ae8fdb0 inode:88006bff60d0
> [   17.185808] Calling filldir with 88006ae8fdb0
>
> So the first line essentially happens when the object 88006ae8fdb0 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: 88006ae8fdb0 inode: 88006bff60d0
> [   17.387601] Assigned fbdev-blacklist.conff(880001eb3020)20 whole 
> object: 88006ae8fdb0 inode:88006bff60d0
> [   17.388740] Calling filldir with 88006ae8fdb0
>
> 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.

Re: kasan behavior when built with unsupported compiler

[Dmitry Vyukov]

On Wed, Mar 8, 2017 at 9:10 AM, Nikolay Borisov
 wrote:
>
>
> On  7.03.2017 17:54, Dmitry Vyukov wrote:
>> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
>>  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(880001ea8020)20 whole 
> object: 88006ae8fdb0 inode:88006bff60d0
> [   17.185808] Calling filldir with 88006ae8fdb0
>
> So the first line essentially happens when the object 88006ae8fdb0 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: 88006ae8fdb0 inode: 88006bff60d0
> [   17.387601] Assigned fbdev-blacklist.conff(880001eb3020)20 whole 
> object: 88006ae8fdb0 inode:88006bff60d0
> [   17.388740] Calling filldir with 88006ae8fdb0
>
> 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.

Re: kasan behavior when built with unsupported compiler

[Nikolay Borisov]

On  7.03.2017 17:54, Dmitry Vyukov wrote:
> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
>  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(880001ea8020)20 whole object: 
88006ae8fdb0 inode:88006bff60d0
[   17.185808] Calling filldir with 88006ae8fdb0

So the first line essentially happens when the object 88006ae8fdb0 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: 88006ae8fdb0 inode: 88006bff60d0
[   17.387601] Assigned fbdev-blacklist.conff(880001eb3020)20 whole object: 
88006ae8fdb0 inode:88006bff60d0
[   17.388740] Calling filldir with 88006ae8fdb0

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. 



> 
> Re why 5.4 does not detect it. Difficult to say.
> If you confirm that it's a real bug and provide repro instructions,
> then I can recheck it with latest gcc. If it's a real bug and the
> latest gcc does not detect it, then we need to look more closely at
> it. I afraid 5.4 won't be fixed.
> It's also possible that it's a false positive in the old compiler (I
> think there were some bugs). If so, I would recommend switching to a
> newer compiler.
> 
diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c
index 68323e3da3fa..31f5153b3df4 100644
--- a/fs/ext4/dir.c
+++ b/fs/ext4/dir.c
@@ -429,6 +429,7 @@ void ext4_htree_free_dir_info(struct dir_private_info *p)
  * encrypted filename, while the htree will hold decrypted filename.
  * The decrypted filename is passed in via ent_name.  parameter.
  */
+void *global_ext4_pointer = NULL;
 int ext4_htree_store_dirent(struct file *dir_file, __u32 hash,
 			 __u32 minor_hash,
 			struct ext4_dir_entry_2 *dirent,
@@ -454,7 +455,10 @@ int ext4_htree_store_dirent(struct file *dir_file, __u32 hash,
 	new_fn->file_type = dirent->file_type;
 	memcpy(new_fn->name, ent_name->name, ent_name->len);
 	new_fn->name[ent_name->len] = 0;
-
+	if (!strcmp(new_fn->name, "fbdev-blacklist.conf")) {
+		pr_info("Assigned %s(%p)%u whole object: %p inode:%p\n", ent_name->name, ent_name->name, ent_name->len, new_fn, file_inode(dir_file));
+		global_ext4_pointer = new_fn; 
+	}
 	while (*p) {
 		parent = *p;
 		fname = rb_entry(parent, struct fname, rb_hash);
@@ -507,6 +511,8 @@ static int call_filldir(struct file *file, struct dir_context *ctx,
 	}
 	ctx->pos = hash2pos(file, fname->hash, fname->minor_hash);
 	while (fname) {
+		if (fname == global_ext4_pointer)
+			pr_info("Calling filldir with %p\n", fname);
 		if (!dir_emit(ctx, fname->name,
 fname->name_len,
 fname->inode,
diff --git a/fs/ext4/extents.c 

Re: kasan behavior when built with unsupported compiler

[Nikolay Borisov]

On  7.03.2017 17:54, Dmitry Vyukov wrote:
> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
>  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(880001ea8020)20 whole object: 
88006ae8fdb0 inode:88006bff60d0
[   17.185808] Calling filldir with 88006ae8fdb0

So the first line essentially happens when the object 88006ae8fdb0 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: 88006ae8fdb0 inode: 88006bff60d0
[   17.387601] Assigned fbdev-blacklist.conff(880001eb3020)20 whole object: 
88006ae8fdb0 inode:88006bff60d0
[   17.388740] Calling filldir with 88006ae8fdb0

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. 



> 
> Re why 5.4 does not detect it. Difficult to say.
> If you confirm that it's a real bug and provide repro instructions,
> then I can recheck it with latest gcc. If it's a real bug and the
> latest gcc does not detect it, then we need to look more closely at
> it. I afraid 5.4 won't be fixed.
> It's also possible that it's a false positive in the old compiler (I
> think there were some bugs). If so, I would recommend switching to a
> newer compiler.
> 
diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c
index 68323e3da3fa..31f5153b3df4 100644
--- a/fs/ext4/dir.c
+++ b/fs/ext4/dir.c
@@ -429,6 +429,7 @@ void ext4_htree_free_dir_info(struct dir_private_info *p)
  * encrypted filename, while the htree will hold decrypted filename.
  * The decrypted filename is passed in via ent_name.  parameter.
  */
+void *global_ext4_pointer = NULL;
 int ext4_htree_store_dirent(struct file *dir_file, __u32 hash,
 			 __u32 minor_hash,
 			struct ext4_dir_entry_2 *dirent,
@@ -454,7 +455,10 @@ int ext4_htree_store_dirent(struct file *dir_file, __u32 hash,
 	new_fn->file_type = dirent->file_type;
 	memcpy(new_fn->name, ent_name->name, ent_name->len);
 	new_fn->name[ent_name->len] = 0;
-
+	if (!strcmp(new_fn->name, "fbdev-blacklist.conf")) {
+		pr_info("Assigned %s(%p)%u whole object: %p inode:%p\n", ent_name->name, ent_name->name, ent_name->len, new_fn, file_inode(dir_file));
+		global_ext4_pointer = new_fn; 
+	}
 	while (*p) {
 		parent = *p;
 		fname = rb_entry(parent, struct fname, rb_hash);
@@ -507,6 +511,8 @@ static int call_filldir(struct file *file, struct dir_context *ctx,
 	}
 	ctx->pos = hash2pos(file, fname->hash, fname->minor_hash);
 	while (fname) {
+		if (fname == global_ext4_pointer)
+			pr_info("Calling filldir with %p\n", fname);
 		if (!dir_emit(ctx, fname->name,
 fname->name_len,
 fname->inode,
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 

Re: kasan behavior when built with unsupported compiler

[Nikolay Borisov]

On  7.03.2017 19:51, Alexander Potapenko wrote:
> On Tue, Mar 7, 2017 at 6:33 PM, Nikolay Borisov
>  wrote:
>>
>>
>> On  7.03.2017 18:05, Alexander Potapenko wrote:
>>> On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov  wrote:
 On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
  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.

 Re why 5.4 does not detect it. Difficult to say.
 If you confirm that it's a real bug and provide repro instructions,
 then I can recheck it with latest gcc. If it's a real bug and the
 latest gcc does not detect it, then we need to look more closely at
 it. I afraid 5.4 won't be fixed.
 It's also possible that it's a false positive in the old compiler (I
 think there were some bugs). If so, I would recommend switching to a
 newer compiler.
>>>
>>> I wonder if there's actual KASAN instrumentation in the kernel in
>>> question built with GCC 4.7.
>>> If there's none, there's little point in investigating this further,
>>> as the tool is anyway barely usable.
>>> Note that the report originates from something like copy_to_user() (or
>>> hard to tell the exact place - Nikolay, could you please symbolize the
>>> report?), i.e. it could be triggered even without KASAN
>>> instrumentation.
>>
>> Of course there is kasan instrumentation, otherwise I won't see kasan 
>> reports, no ?
> Not necessarily.
> There's KASAN instrumentation inserted by the compiler, and KASAN
> instrumentation added manually to the places the compiler can't
> instrument.
>> I bisected this to commit 1771c6e1a567ea0ba2cc which adds user memory access 
>> API
> Commit 1771c6e1a567ea0ba2cc added exactly these calls to
> check_memory_region() you are seeing.
> If there is any other instrumentation inserted by the compiler, it's
> possible that it may catch accesses to the same object (if something
> else except copy_to_user() is being done).
> Otherwise the only thing you can do to investigate this bug with GCC
> 4.7 is to bisect further by rolling to earlier revisions and applying
> 1771c6e1a567ea0ba2cc on top of them.
> I won't be surprised though if at some point the bisection may stop
> for a different reason.
>> instrumentation. Here is a symbolized report:
>>
>> ==
>> BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr 88006a22560e
>> Read of size 20 by task systemd/1
>> =
>> BUG kmalloc-96 (Not tainted): kasan: bad access detected
>> -
>>
>> Disabling lock debugging due to kernel taint
>> INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=0 cpu=2 pid=1
>> [] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446
>> [] __slab_alloc+0x4f/0x86 mm/slub.c:2475
>> [< inline >] slab_alloc_node mm/slub.c:2538
>> [< inline >] slab_alloc mm/slub.c:2580
>> [] __kmalloc+0x27a/0x340 mm/slub.c:3561
>> [< inline >] kmalloc include/linux/slab.h:483
>> [< inline >] kzalloc include/linux/slab.h:622
>> [] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447
>> [] 

Re: kasan behavior when built with unsupported compiler

[Nikolay Borisov]

On  7.03.2017 19:51, Alexander Potapenko wrote:
> On Tue, Mar 7, 2017 at 6:33 PM, Nikolay Borisov
>  wrote:
>>
>>
>> On  7.03.2017 18:05, Alexander Potapenko wrote:
>>> On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov  wrote:
 On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
  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.

 Re why 5.4 does not detect it. Difficult to say.
 If you confirm that it's a real bug and provide repro instructions,
 then I can recheck it with latest gcc. If it's a real bug and the
 latest gcc does not detect it, then we need to look more closely at
 it. I afraid 5.4 won't be fixed.
 It's also possible that it's a false positive in the old compiler (I
 think there were some bugs). If so, I would recommend switching to a
 newer compiler.
>>>
>>> I wonder if there's actual KASAN instrumentation in the kernel in
>>> question built with GCC 4.7.
>>> If there's none, there's little point in investigating this further,
>>> as the tool is anyway barely usable.
>>> Note that the report originates from something like copy_to_user() (or
>>> hard to tell the exact place - Nikolay, could you please symbolize the
>>> report?), i.e. it could be triggered even without KASAN
>>> instrumentation.
>>
>> Of course there is kasan instrumentation, otherwise I won't see kasan 
>> reports, no ?
> Not necessarily.
> There's KASAN instrumentation inserted by the compiler, and KASAN
> instrumentation added manually to the places the compiler can't
> instrument.
>> I bisected this to commit 1771c6e1a567ea0ba2cc which adds user memory access 
>> API
> Commit 1771c6e1a567ea0ba2cc added exactly these calls to
> check_memory_region() you are seeing.
> If there is any other instrumentation inserted by the compiler, it's
> possible that it may catch accesses to the same object (if something
> else except copy_to_user() is being done).
> Otherwise the only thing you can do to investigate this bug with GCC
> 4.7 is to bisect further by rolling to earlier revisions and applying
> 1771c6e1a567ea0ba2cc on top of them.
> I won't be surprised though if at some point the bisection may stop
> for a different reason.
>> instrumentation. Here is a symbolized report:
>>
>> ==
>> BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr 88006a22560e
>> Read of size 20 by task systemd/1
>> =
>> BUG kmalloc-96 (Not tainted): kasan: bad access detected
>> -
>>
>> Disabling lock debugging due to kernel taint
>> INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=0 cpu=2 pid=1
>> [] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446
>> [] __slab_alloc+0x4f/0x86 mm/slub.c:2475
>> [< inline >] slab_alloc_node mm/slub.c:2538
>> [< inline >] slab_alloc mm/slub.c:2580
>> [] __kmalloc+0x27a/0x340 mm/slub.c:3561
>> [< inline >] kmalloc include/linux/slab.h:483
>> [< inline >] kzalloc include/linux/slab.h:622
>> [] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447
>> [] htree_dirblock_to_tree+0x16a/0x190 
>> fs/ext4/namei.c:1001
>> [] 

Re: kasan behavior when built with unsupported compiler

[Alexander Potapenko]

On Tue, Mar 7, 2017 at 6:33 PM, Nikolay Borisov
 wrote:
>
>
> On  7.03.2017 18:05, Alexander Potapenko wrote:
>> On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov  wrote:
>>> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
>>>  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.
>>>
>>> Re why 5.4 does not detect it. Difficult to say.
>>> If you confirm that it's a real bug and provide repro instructions,
>>> then I can recheck it with latest gcc. If it's a real bug and the
>>> latest gcc does not detect it, then we need to look more closely at
>>> it. I afraid 5.4 won't be fixed.
>>> It's also possible that it's a false positive in the old compiler (I
>>> think there were some bugs). If so, I would recommend switching to a
>>> newer compiler.
>>
>> I wonder if there's actual KASAN instrumentation in the kernel in
>> question built with GCC 4.7.
>> If there's none, there's little point in investigating this further,
>> as the tool is anyway barely usable.
>> Note that the report originates from something like copy_to_user() (or
>> hard to tell the exact place - Nikolay, could you please symbolize the
>> report?), i.e. it could be triggered even without KASAN
>> instrumentation.
>
> Of course there is kasan instrumentation, otherwise I won't see kasan 
> reports, no ?
Not necessarily.
There's KASAN instrumentation inserted by the compiler, and KASAN
instrumentation added manually to the places the compiler can't
instrument.
> I bisected this to commit 1771c6e1a567ea0ba2cc which adds user memory access 
> API
Commit 1771c6e1a567ea0ba2cc added exactly these calls to
check_memory_region() you are seeing.
If there is any other instrumentation inserted by the compiler, it's
possible that it may catch accesses to the same object (if something
else except copy_to_user() is being done).
Otherwise the only thing you can do to investigate this bug with GCC
4.7 is to bisect further by rolling to earlier revisions and applying
1771c6e1a567ea0ba2cc on top of them.
I won't be surprised though if at some point the bisection may stop
for a different reason.
> instrumentation. Here is a symbolized report:
>
> ==
> BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr 88006a22560e
> Read of size 20 by task systemd/1
> =
> BUG kmalloc-96 (Not tainted): kasan: bad access detected
> -
>
> Disabling lock debugging due to kernel taint
> INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=0 cpu=2 pid=1
> [] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446
> [] __slab_alloc+0x4f/0x86 mm/slub.c:2475
> [< inline >] slab_alloc_node mm/slub.c:2538
> [< inline >] slab_alloc mm/slub.c:2580
> [] __kmalloc+0x27a/0x340 mm/slub.c:3561
> [< inline >] kmalloc include/linux/slab.h:483
> [< inline >] kzalloc include/linux/slab.h:622
> [] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447
> [] htree_dirblock_to_tree+0x16a/0x190 
> fs/ext4/namei.c:1001
> [] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075
> [< inline >] ext4_dx_readdir 

Re: kasan behavior when built with unsupported compiler

[Alexander Potapenko]

On Tue, Mar 7, 2017 at 6:33 PM, Nikolay Borisov
 wrote:
>
>
> On  7.03.2017 18:05, Alexander Potapenko wrote:
>> On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov  wrote:
>>> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
>>>  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.
>>>
>>> Re why 5.4 does not detect it. Difficult to say.
>>> If you confirm that it's a real bug and provide repro instructions,
>>> then I can recheck it with latest gcc. If it's a real bug and the
>>> latest gcc does not detect it, then we need to look more closely at
>>> it. I afraid 5.4 won't be fixed.
>>> It's also possible that it's a false positive in the old compiler (I
>>> think there were some bugs). If so, I would recommend switching to a
>>> newer compiler.
>>
>> I wonder if there's actual KASAN instrumentation in the kernel in
>> question built with GCC 4.7.
>> If there's none, there's little point in investigating this further,
>> as the tool is anyway barely usable.
>> Note that the report originates from something like copy_to_user() (or
>> hard to tell the exact place - Nikolay, could you please symbolize the
>> report?), i.e. it could be triggered even without KASAN
>> instrumentation.
>
> Of course there is kasan instrumentation, otherwise I won't see kasan 
> reports, no ?
Not necessarily.
There's KASAN instrumentation inserted by the compiler, and KASAN
instrumentation added manually to the places the compiler can't
instrument.
> I bisected this to commit 1771c6e1a567ea0ba2cc which adds user memory access 
> API
Commit 1771c6e1a567ea0ba2cc added exactly these calls to
check_memory_region() you are seeing.
If there is any other instrumentation inserted by the compiler, it's
possible that it may catch accesses to the same object (if something
else except copy_to_user() is being done).
Otherwise the only thing you can do to investigate this bug with GCC
4.7 is to bisect further by rolling to earlier revisions and applying
1771c6e1a567ea0ba2cc on top of them.
I won't be surprised though if at some point the bisection may stop
for a different reason.
> instrumentation. Here is a symbolized report:
>
> ==
> BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr 88006a22560e
> Read of size 20 by task systemd/1
> =
> BUG kmalloc-96 (Not tainted): kasan: bad access detected
> -
>
> Disabling lock debugging due to kernel taint
> INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=0 cpu=2 pid=1
> [] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446
> [] __slab_alloc+0x4f/0x86 mm/slub.c:2475
> [< inline >] slab_alloc_node mm/slub.c:2538
> [< inline >] slab_alloc mm/slub.c:2580
> [] __kmalloc+0x27a/0x340 mm/slub.c:3561
> [< inline >] kmalloc include/linux/slab.h:483
> [< inline >] kzalloc include/linux/slab.h:622
> [] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447
> [] htree_dirblock_to_tree+0x16a/0x190 
> fs/ext4/namei.c:1001
> [] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075
> [< inline >] ext4_dx_readdir fs/ext4/dir.c:571
> [] ext4_readdir+0x698/0x950 

Re: kasan behavior when built with unsupported compiler

[Nikolay Borisov]

On  7.03.2017 18:05, Alexander Potapenko wrote:
> On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov  wrote:
>> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
>>  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.
>>
>> Re why 5.4 does not detect it. Difficult to say.
>> If you confirm that it's a real bug and provide repro instructions,
>> then I can recheck it with latest gcc. If it's a real bug and the
>> latest gcc does not detect it, then we need to look more closely at
>> it. I afraid 5.4 won't be fixed.
>> It's also possible that it's a false positive in the old compiler (I
>> think there were some bugs). If so, I would recommend switching to a
>> newer compiler.
> 
> I wonder if there's actual KASAN instrumentation in the kernel in
> question built with GCC 4.7.
> If there's none, there's little point in investigating this further,
> as the tool is anyway barely usable.
> Note that the report originates from something like copy_to_user() (or
> hard to tell the exact place - Nikolay, could you please symbolize the
> report?), i.e. it could be triggered even without KASAN
> instrumentation.

Of course there is kasan instrumentation, otherwise I won't see kasan reports, 
no ? 
I bisected this to commit 1771c6e1a567ea0ba2cc which adds user memory access 
API 
instrumentation. Here is a symbolized report: 

==
BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr 88006a22560e
Read of size 20 by task systemd/1
=
BUG kmalloc-96 (Not tainted): kasan: bad access detected
-

Disabling lock debugging due to kernel taint
INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=0 cpu=2 pid=1
[] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446
[] __slab_alloc+0x4f/0x86 mm/slub.c:2475
[< inline >] slab_alloc_node mm/slub.c:2538
[< inline >] slab_alloc mm/slub.c:2580
[] __kmalloc+0x27a/0x340 mm/slub.c:3561
[< inline >] kmalloc include/linux/slab.h:483
[< inline >] kzalloc include/linux/slab.h:622
[] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447
[] htree_dirblock_to_tree+0x16a/0x190 fs/ext4/namei.c:1001
[] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075
[< inline >] ext4_dx_readdir fs/ext4/dir.c:571
[] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121
[] iterate_dir+0x7d/0x190 fs/readdir.c:50
[< inline >] SYSC_getdents fs/readdir.c:230
[] SyS_getdents+0x91/0x120 fs/readdir.c:212
[] entry_SYSCALL_64_fastpath+0x23/0xc1 
arch/x86/entry/entry_64.S:207

INFO: Freed in ext4_ext_map_blocks+0x7f9/0x23e0 age=1 cpu=2 pid=1
[] __slab_free+0x31b/0x440 mm/slub.c:2657
[< inline >] slab_free mm/slub.c:2810
[] kfree+0x27f/0x2d0 mm/slub.c:3662
[] ext4_ext_map_blocks+0x7f9/0x23e0 fs/ext4/extents.c:4619
[] ext4_map_blocks+0x3b4/0x5b0 fs/ext4/inode.c:529
[] ext4_getblk+0x54/0x1a0 fs/ext4/inode.c:929
[] ext4_bread+0x13/0x90 fs/ext4/inode.c:979
[] 

Re: kasan behavior when built with unsupported compiler

[Nikolay Borisov]

On  7.03.2017 18:05, Alexander Potapenko wrote:
> On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov  wrote:
>> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
>>  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.
>>
>> Re why 5.4 does not detect it. Difficult to say.
>> If you confirm that it's a real bug and provide repro instructions,
>> then I can recheck it with latest gcc. If it's a real bug and the
>> latest gcc does not detect it, then we need to look more closely at
>> it. I afraid 5.4 won't be fixed.
>> It's also possible that it's a false positive in the old compiler (I
>> think there were some bugs). If so, I would recommend switching to a
>> newer compiler.
> 
> I wonder if there's actual KASAN instrumentation in the kernel in
> question built with GCC 4.7.
> If there's none, there's little point in investigating this further,
> as the tool is anyway barely usable.
> Note that the report originates from something like copy_to_user() (or
> hard to tell the exact place - Nikolay, could you please symbolize the
> report?), i.e. it could be triggered even without KASAN
> instrumentation.

Of course there is kasan instrumentation, otherwise I won't see kasan reports, 
no ? 
I bisected this to commit 1771c6e1a567ea0ba2cc which adds user memory access 
API 
instrumentation. Here is a symbolized report: 

==
BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr 88006a22560e
Read of size 20 by task systemd/1
=
BUG kmalloc-96 (Not tainted): kasan: bad access detected
-

Disabling lock debugging due to kernel taint
INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=0 cpu=2 pid=1
[] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446
[] __slab_alloc+0x4f/0x86 mm/slub.c:2475
[< inline >] slab_alloc_node mm/slub.c:2538
[< inline >] slab_alloc mm/slub.c:2580
[] __kmalloc+0x27a/0x340 mm/slub.c:3561
[< inline >] kmalloc include/linux/slab.h:483
[< inline >] kzalloc include/linux/slab.h:622
[] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447
[] htree_dirblock_to_tree+0x16a/0x190 fs/ext4/namei.c:1001
[] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075
[< inline >] ext4_dx_readdir fs/ext4/dir.c:571
[] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121
[] iterate_dir+0x7d/0x190 fs/readdir.c:50
[< inline >] SYSC_getdents fs/readdir.c:230
[] SyS_getdents+0x91/0x120 fs/readdir.c:212
[] entry_SYSCALL_64_fastpath+0x23/0xc1 
arch/x86/entry/entry_64.S:207

INFO: Freed in ext4_ext_map_blocks+0x7f9/0x23e0 age=1 cpu=2 pid=1
[] __slab_free+0x31b/0x440 mm/slub.c:2657
[< inline >] slab_free mm/slub.c:2810
[] kfree+0x27f/0x2d0 mm/slub.c:3662
[] ext4_ext_map_blocks+0x7f9/0x23e0 fs/ext4/extents.c:4619
[] ext4_map_blocks+0x3b4/0x5b0 fs/ext4/inode.c:529
[] ext4_getblk+0x54/0x1a0 fs/ext4/inode.c:929
[] ext4_bread+0x13/0x90 fs/ext4/inode.c:979
[] __ext4_read_dirblock+0x3f/0x380 

Re: kasan behavior when built with unsupported compiler

[Dmitry Vyukov]

On Tue, Mar 7, 2017 at 5:26 PM, Andrey Ryabinin  wrote:
>
>
> On 03/07/2017 06:54 PM, Dmitry Vyukov wrote:
>
>>
>> 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.
>
> You made this up, we don't have such plugin.

Right. It was KCOV.

Re: kasan behavior when built with unsupported compiler

[Dmitry Vyukov]

On Tue, Mar 7, 2017 at 5:26 PM, Andrey Ryabinin  wrote:
>
>
> On 03/07/2017 06:54 PM, Dmitry Vyukov wrote:
>
>>
>> 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.
>
> You made this up, we don't have such plugin.

Right. It was KCOV.

Re: kasan behavior when built with unsupported compiler

[Andrey Ryabinin]

On 03/07/2017 06:35 PM, Nikolay Borisov wrote:
> Hello,
> 
> I've been chasing a particular UAF as reported by kasan
> (https://www.spinics.net/lists/kernel/msg2458136.html). 

AFAICS it's not use after free, it's out-of-bounds access.

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

With gcc like 4.7.4 compiler will not instrument memory accesses in code, which 
means
that kasan will not detect bugs. However, in your case, access is done via 
copy_to_user().

Compiler doesn't see accesses in copy_to_user() because it's written in 
assembly, thus
we added manual check in commit 1771c6e1a567ea0ba20a4ffe68a1419fd8ef.
Of course this manual check will work with any compiler version.


> If, however, I build the kernel
> with a newer compiler version 5.4.0 kasan no longer complains.
> 

That's odd. Perhaps we have some tricky bug triggered by gcc 4.7.4 code 
generation
or it might be some bug in gcc. But it's just a blind guess, it's hard to say 
anything
for sure without further analysis.

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

So with GCCs that doesn't support kasan we shouldn't have any false-positives,
but it's expected to have a lot of false-negatives (missed bugs).



> 
> Regards,
> Nikolay
> 

Re: kasan behavior when built with unsupported compiler

[Andrey Ryabinin]

On 03/07/2017 06:35 PM, Nikolay Borisov wrote:
> Hello,
> 
> I've been chasing a particular UAF as reported by kasan
> (https://www.spinics.net/lists/kernel/msg2458136.html). 

AFAICS it's not use after free, it's out-of-bounds access.

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

With gcc like 4.7.4 compiler will not instrument memory accesses in code, which 
means
that kasan will not detect bugs. However, in your case, access is done via 
copy_to_user().

Compiler doesn't see accesses in copy_to_user() because it's written in 
assembly, thus
we added manual check in commit 1771c6e1a567ea0ba20a4ffe68a1419fd8ef.
Of course this manual check will work with any compiler version.


> If, however, I build the kernel
> with a newer compiler version 5.4.0 kasan no longer complains.
> 

That's odd. Perhaps we have some tricky bug triggered by gcc 4.7.4 code 
generation
or it might be some bug in gcc. But it's just a blind guess, it's hard to say 
anything
for sure without further analysis.

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

So with GCCs that doesn't support kasan we shouldn't have any false-positives,
but it's expected to have a lot of false-negatives (missed bugs).



> 
> Regards,
> Nikolay
> 

Re: kasan behavior when built with unsupported compiler

[Alexander Potapenko]

On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov  wrote:
> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
>  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.
>
> Re why 5.4 does not detect it. Difficult to say.
> If you confirm that it's a real bug and provide repro instructions,
> then I can recheck it with latest gcc. If it's a real bug and the
> latest gcc does not detect it, then we need to look more closely at
> it. I afraid 5.4 won't be fixed.
> It's also possible that it's a false positive in the old compiler (I
> think there were some bugs). If so, I would recommend switching to a
> newer compiler.

I wonder if there's actual KASAN instrumentation in the kernel in
question built with GCC 4.7.
If there's none, there's little point in investigating this further,
as the tool is anyway barely usable.
Note that the report originates from something like copy_to_user() (or
hard to tell the exact place - Nikolay, could you please symbolize the
report?), i.e. it could be triggered even without KASAN
instrumentation.

-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Re: kasan behavior when built with unsupported compiler

[Alexander Potapenko]

On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov  wrote:
> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
>  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.
>
> Re why 5.4 does not detect it. Difficult to say.
> If you confirm that it's a real bug and provide repro instructions,
> then I can recheck it with latest gcc. If it's a real bug and the
> latest gcc does not detect it, then we need to look more closely at
> it. I afraid 5.4 won't be fixed.
> It's also possible that it's a false positive in the old compiler (I
> think there were some bugs). If so, I would recommend switching to a
> newer compiler.

I wonder if there's actual KASAN instrumentation in the kernel in
question built with GCC 4.7.
If there's none, there's little point in investigating this further,
as the tool is anyway barely usable.
Note that the report originates from something like copy_to_user() (or
hard to tell the exact place - Nikolay, could you please symbolize the
report?), i.e. it could be triggered even without KASAN
instrumentation.

-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Re: kasan behavior when built with unsupported compiler

[Andrey Ryabinin]

On 03/07/2017 06:54 PM, Dmitry Vyukov wrote:

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

You made this up, we don't have such plugin.

Re: kasan behavior when built with unsupported compiler

[Andrey Ryabinin]

On 03/07/2017 06:54 PM, Dmitry Vyukov wrote:

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

You made this up, we don't have such plugin.

Re: kasan behavior when built with unsupported compiler

[Dmitry Vyukov]

On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
 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.

Re why 5.4 does not detect it. Difficult to say.
If you confirm that it's a real bug and provide repro instructions,
then I can recheck it with latest gcc. If it's a real bug and the
latest gcc does not detect it, then we need to look more closely at
it. I afraid 5.4 won't be fixed.
It's also possible that it's a false positive in the old compiler (I
think there were some bugs). If so, I would recommend switching to a
newer compiler.

Re: kasan behavior when built with unsupported compiler

[Dmitry Vyukov]

On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
 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.

Re why 5.4 does not detect it. Difficult to say.
If you confirm that it's a real bug and provide repro instructions,
then I can recheck it with latest gcc. If it's a real bug and the
latest gcc does not detect it, then we need to look more closely at
it. I afraid 5.4 won't be fixed.
It's also possible that it's a false positive in the old compiler (I
think there were some bugs). If so, I would recommend switching to a
newer compiler.