Messages in this thread | | | From | Dmitry Vyukov <> | Date | Wed, 8 Mar 2017 13:34:24 +0100 | Subject | Re: 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.
| |