Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1571562

Re: keys: GPF in request_key

Show all headers | View raw

On Wed, Feb 1, 2017 at 2:11 PM, David Howells <dhowells@redhat.com> wrote:
> Dmitry Vyukov <dvyukov@google.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.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

keys: GPF in request_key Dmitry Vyukov <dvyukov@google.com> - 2017-02-01 13:30 +0100
  Re: keys: GPF in request_key David Howells <dhowells@redhat.com> - 2017-02-01 14:20 +0100
    Re: keys: GPF in request_key Dmitry Vyukov <dvyukov@google.com> - 2017-02-01 14:30 +0100
  Re: keys: GPF in request_key David Howells <dhowells@redhat.com> - 2017-02-01 14:30 +0100
  Re: keys: GPF in request_key David Howells <dhowells@redhat.com> - 2017-02-01 14:50 +0100
    Re: keys: GPF in request_key Dmitry Vyukov <dvyukov@google.com> - 2017-02-01 15:10 +0100
      Re: keys: GPF in request_key David Howells <dhowells@redhat.com> - 2017-02-01 16:00 +0100
        Re: keys: GPF in request_key Dmitry Vyukov <dvyukov@google.com> - 2017-02-01 16:30 +0100
          Re: keys: GPF in request_key David Howells <dhowells@redhat.com> - 2017-02-01 16:50 +0100
            Re: keys: GPF in request_key Dmitry Vyukov <dvyukov@google.com> - 2017-02-01 17:00 +0100
              Re: keys: GPF in request_key David Howells <dhowells@redhat.com> - 2017-02-01 18:00 +0100
                Re: keys: GPF in request_key Dmitry Vyukov <dvyukov@google.com> - 2017-02-01 18:20 +0100

csiph-web