linux-kernel - Re: keys: GPF in request

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+b-DdC-6uLq+VOCcS=3ZFrzE5n_R2+7KR2BQRh7tP2Lfg@mail.gmail.com>
Date:   Wed, 1 Feb 2017 14:23:04 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     David Howells <dhowells@...hat.com>
Cc:     james.l.morris@...cle.com, serge@...lyn.com,
        keyrings@...r.kernel.org, linux-security-module@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller <syzkaller@...glegroups.com>
Subject: Re: keys: GPF in request_key

On Wed, Feb 1, 2017 at 2:11 PM, David Howells <dhowells@...hat.com> wrote:
> Dmitry Vyukov <dvyukov@...gle.com> wrote:
>
>> Code: 41 54 49 89 f4 53 49 89 d7 48 89 fb 48 83 ec 08 e8 d1 50 67 ff
>> 49 8d 7c 24 10 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
>> 3c 02 00 0f 85 35 02 00 00 49 83 7c 24 10 00 0f 84 bb 01 00
>
> This disassembles to:
>
>    0:   41 54                   push   %r12
>    2:   49 89 f4                mov    %rsi,%r12
>    5:   53                      push   %rbx
>    6:   49 89 d7                mov    %rdx,%r15
>    9:   48 89 fb                mov    %rdi,%rbx
>    c:   48 83 ec 08             sub    $0x8,%rsp
>   10:   e8 d1 50 67 ff          callq  0xffffffffff6750e6
>   15:   49 8d 7c 24 10          lea    0x10(%r12),%rdi
>   1a:   48 b8 00 00 00 00 00    movabs $0xdffffc0000000000,%rax
>   21:   fc ff df
>   24:   48 89 fa                mov    %rdi,%rdx
>   27:   48 c1 ea 03             shr    $0x3,%rdx
>   2b:*  80 3c 02 00             cmpb   $0x0,(%rdx,%rax,1)               <-- trapping instruction
>   2f:   0f 85 35 02 00 00       jne    0x26a
>   35:   49 83 7c 24 10 00       cmpq   $0x0,0x10(%r12)
>   3b:   0f                      .byte 0xf
>   3c:   84                      .byte 0x84
>   3d:   bb                      .byte 0xbb
>   3e:   01 00                   add    %eax,(%rax)
>
> I can see that RAX got loaded from the instruction at 0x1a, but the code
> doesn't look very much like what I get out of the compiler (your compiled
> function is also at least double the size of what I get, presumably due to
> kasan?).
>
> Can you disassemble __key_link_begin() for me and send me your config?
>
> In particular, 0xdffffc0000000000 looks very weird.  Is this code validating
> the pointer in R12?


Here is the disasm:
https://gist.githubusercontent.com/dvyukov/c06f742adba0ee162dfb1ece75b5d8ab/raw/14aba22492090e09ea36bddd5db344fdcfc25065/gistfile1.txt

Yes, this is with KASAN+KCOV so size increase is expected.

Before each memory access to *p KASAN inserts:

if (*(char*)(0xdffffc0000000000 + p/8)) __kasan_report();
... *p .... // original memory accesses

You can see it here:

ffffffff8203ea84: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax
ffffffff8203ea8b: fc ff df
ffffffff8203ea8e: 48 89 fa             mov    %rdi,%rdx
ffffffff8203ea91: 48 c1 ea 03           shr    $0x3,%rdx
ffffffff8203ea95: 80 3c 02 00           cmpb   $0x0,(%rdx,%rax,1) //
<<< ACCESS that crashes

For valid kernel addresses this never crashes.
In this case the original addresses that code tried to accesses is in
%RDI. And they look bogus.