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