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