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  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:17:44 +0100
From:   Arnd Bergmann <>
To:     Mark Rutland <>
Cc:     Dmitry Vyukov <>,
        Andrey Ryabinin <>,
        kasan-dev <>,
        Alexander Potapenko <>,
        LKML <>,
        Linux ARM <>,
        Dennis Zhou <>,
        Fengguang Wu <>
Subject: Re: kasan: false use-after-scope warnings with KCOV

On Tue, Nov 28, 2017 at 4:24 PM, Mark Rutland <> wrote:
> On Tue, Nov 28, 2017 at 02:13:55PM +0000, Mark Rutland wrote:
>> On Tue, Nov 28, 2017 at 01:57:49PM +0100, Dmitry Vyukov wrote:
>> > On Tue, Nov 28, 2017 at 1:35 PM, Mark Rutland <> 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

Maybe it's better to just completely disable  -fsanitize-address-use-after-scope
when it has multiple independent problems.


Powered by blists - more mailing lists