kasan: false use-after-scope warnings with KCOV

[Mark Rutland]

On Tue, Nov 28, 2017 at 06:52:32PM +0100, Dmitry Vyukov wrote:
> On Tue, Nov 28, 2017 at 4:24 PM, Mark Rutland <mark.rutland at arm.com> 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.
> >
> > Unfortunately, there's not enough information left to say where exactly
> > that happened.
> >
> > Given the report that Andrey linked to [1], it looks like the compiler
> > is doing something wrong, and failing to clear some poison in some
> > cases. Dennis noted [2] that this appears to be the case where inline
> > functions are called in a loop.
> >
> > It sounds like this is a general GCC 7.x problem, on both x86_64 and
> > arm64. As we don't have a smoking gun, it's still possible that
> > something else is corrupting the shadow, but it seems unlikely.
> 
> We use gcc 7.1 extensively on x86_64 and have not seen any problems.

FWIW, it looks like ASAN does go wrong on x86 under some conditions:

https://lkml.kernel.org/r/20171129175430.GA58181@big-sky.attlocal.net

I note that in all cases reported so far, there's a GCC plugin involved,
so perhaps there's some bad interaction between the compiler passes.

Thanks,
Mark.