linux-kernel - 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-next>] [day] [month] [year] [list]

Message-ID: <1eb0b1ba-3847-9bdc-8f4a-adcd34de3486@gmail.com>
Date:   Tue, 7 Mar 2017 17:35:42 +0200
From:   Nikolay Borisov <n.borisov.lkml@...il.com>
To:     aryabinin@...tuozzo.com
Cc:     glider@...gle.com, Dmitry Vyukov <dvyukov@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: kasan behavior when built with unsupported compiler

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 ?

Regards,
Nikolay