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]

Message-ID: <CACT4Y+Zs9g7KDqz7cp9A_5jCNkRc0dfoXfupFLFfn73p3X3=vg@mail.gmail.com>
Date:   Wed, 29 Nov 2017 12:41:05 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Mark Rutland <mark.rutland@....com>
Cc:     Andrey Ryabinin <aryabinin@...tuozzo.com>,
        kasan-dev <kasan-dev@...glegroups.com>,
        Alexander Potapenko <glider@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        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 12:26 PM, Mark Rutland <mark.rutland@....com> wrote:
> 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@....com> wrote:
>
>> >> ... 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.
>
>> 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 at 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).