Thread (12 messages) flat view 12 messages, 4 authors, 2017-11-30

kasan: false use-after-scope warnings with KCOV

From: dvyukov@google.com (Dmitry Vyukov)
Date: 2017-11-29 20:56:41
Also in: lkml

On Wed, Nov 29, 2017 at 9:17 PM, Arnd Bergmann [off-list ref] wrote:
quoted
quoted
quoted
quoted
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.
quoted
... 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help