linux-kernel - Re: kasan: false use-after-scope warnings with KCOV

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:   Wed, 29 Nov 2017 21:56:17 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Mark Rutland <mark.rutland@....com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        kasan-dev <kasan-dev@...glegroups.com>,
        Alexander Potapenko <glider@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Dennis Zhou <dennisszhou@...il.com>,
        Fengguang Wu <fengguang.wu@...el.com>
Subject: Re: kasan: false use-after-scope warnings with KCOV

On Wed, Nov 29, 2017 at 9:17 PM, Arnd Bergmann <arnd@...db.de> wrote:
>>> > > As a heads-up, I'm seeing a number of what appear to be false-positive
>>> > > use-after-scope warnings when I enable both KCOV and KASAN (inline or outline),
>>> > > when using the Linaro 17.08 GCC7.1.1 for arm64. So far I haven't spotted these
>>> > > without KCOV selected, and I'm only seeing these for sanitize-use-after-scope.
>>> > >
>>> > > The reports vary depending on configuration even with the same trigger. I'm not
>>> > > sure if it's the reporting that's misleading, or whether the detection is going
>>> > > wrong.
>>
>>> ... it looks suspiciously like something is setting up non-zero shadow
>>> bytes, but not zeroing them upon return.
>>
>> It looks like this is the case.
>>
>> The hack below detects leftover poison on an exception return *before*
>> the false-positive warning (example splat at the end of the email). With
>> scripts/Makefile.kasan hacked to not pass
>> -fsanitize-address-use-after-scope, I see no leftover poison.
>
> That reminds me that we are still missing my patch to turn off
> -fsanitize-address-use-after-scope by default and instead re-enable
> CONFIG_FRAME_WARN when KASAN is turned on.
>
> I spent about a year hunting down all the instances that produce more
> than 2KB stack frames with KASAN (including asan-stack), they should
> be disabled now, but we still have some seriously large stack frames with
>  -fsanitize-address-use-after-scope.
>
> Maybe it's better to just completely disable  -fsanitize-address-use-after-scope
> when it has multiple independent problems.


This one is not a problem with KASAN. KASAN has detected a very real
and subtle bug in the code.