kasan: false use-after-scope warnings with KCOV

On Wed, Nov 29, 2017 at 12:26 PM, Mark Rutland [off-list ref] wrote:

On Tue, Nov 28, 2017 at 06:52:32PM +0100, Dmitry Vyukov wrote:

quoted

On Tue, Nov 28, 2017 at 4:24 PM, Mark Rutland [off-list ref] wrote:

quoted

quoted

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.

Unfortunately, there's not enough information left to say where exactly
that happened.

quoted

ASAN stack instrumentation actually contains information about frames.
I just never got around to using it in KASAN. But user-space ASAN
prints the following on stack bugs:

Address 0x7ffdb1c75140 is located in stack of thread T0 at offset 64 in frame
    #0 0x527fff  in main test.c:5

  This frame has 2 object(s):
    [32, 40) 'p'
    [64, 68) 'x' <== Memory access@offset 64 is inside this variable

Function prologue contains code similar to this:

  528062:       48 ba f0 7f 52 00 00    movabs $0x527ff0,%rdx
  52806c:       48 be 9c e5 53 00 00    movabs $0x53e59c,%rsi
  528076:       48 89 c7                mov    %rax,%rdi
  528079:       48 83 c7 20             add    $0x20,%rdi
  52807d:       49 89 c0                mov    %rax,%r8
  528080:       49 83 c0 40             add    $0x40,%r8
  528084:       48 c7 00 b3 8a b5 41    movq   $0x41b58ab3,(%rax)
  52808b:       48 89 70 08             mov    %rsi,0x8(%rax)
  52808f:       48 89 50 10             mov    %rdx,0x10(%rax)

Here 0x41b58ab3 is marker of frame start, and after it 0x527ff0 and
0x53e59c should be pointers to globals that contain function name and
other aux information. Note that's on stack itself, not in shadow.
If you can find any of 0x41b58ab3 in the corrupted part of stack, you
can figure out what function has left garbage.

Thanks for the info! I'll try to give this a go, but I'm probably not
going to have the chance to investigate much this week.

I'm afraid I'm not that good at reading x86 assembly. IIUC there are
records on the stack something like:

struct record {
        u64 magic; /* 0x41b58ab3 */
        char *func_name;
        struct aux *data;
};

... is that correct?

Is there any documentation on this that I can refer to?

I am not aware of any documentation other than code. I think the
simplest is AsanThread::GetStackFrameAccessByAddr() here:
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/asan/asan_thread.cc?revision=310432&view=markup
It finds the struct with description from the bad access address.
Looking at the code, yes, there is magic, then char* frame
descriptions, and then PC where the frame was allocated (usually
function prologue, but I think can also point to an alloca).