| 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
| ||
|
Date: Wed, 07 May 2014 12:51:28 -0700 From: Andy Lutomirski <luto@...capital.net> To: Steven Rostedt <rostedt@...dmis.org>, Sasha Levin <sasha.levin@...cle.com> CC: Oleg Nesterov <oleg@...hat.com>, roland@...hat.com, LKML <linux-kernel@...r.kernel.org>, Dave Jones <davej@...hat.com>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com> Subject: Re: ptrace: gpf in syscall_trace_enter On 05/07/2014 09:06 AM, Steven Rostedt wrote: > [ adding Mathieu as well, as this is tracepoint code ] > > On Wed, 07 May 2014 11:23:36 -0400 > Sasha Levin <sasha.levin@...cle.com> wrote: > >> On 05/07/2014 10:31 AM, Steven Rostedt wrote: >>> On Wed, 7 May 2014 16:04:22 +0200 >>> Oleg Nesterov <oleg@...hat.com> wrote: >>> >>>> On 05/06, Sasha Levin wrote: >>>>> >>>>> On 05/06/2014 08:36 PM, Sasha Levin wrote: >>>>>> Hi all, >>>>>> >>>>>> While fuzzing with trinity inside a KVM tools guest running the latest -next >>>>>> kernel I've stumbled on the following spew: >>>>> >>>>> And another similar trace: >>>> >>>> Again, this looks like __DO_TRACE() trying to call it_func_ptr->func(). >>> >>> Really? Can I see an objdump of the location of the crash. Preferably >>> the entire function. >> >> 0000000000002740 <syscall_trace_leave>: >> 2740: e8 00 00 00 00 callq 2745 <syscall_trace_leave+0x5> >> 2741: R_X86_64_PC32 __fentry__-0x4 >> 2745: 55 push %rbp >> 2746: 48 89 e5 mov %rsp,%rbp >> 2749: 48 83 ec 20 sub $0x20,%rsp >> 274d: 48 89 5d e8 mov %rbx,-0x18(%rbp) >> 2751: 48 89 fb mov %rdi,%rbx >> 2754: 4c 89 65 f0 mov %r12,-0x10(%rbp) >> 2758: 4c 89 6d f8 mov %r13,-0x8(%rbp) >> 275c: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) >> 2761: 65 48 8b 04 25 00 00 mov %gs:0x0,%rax >> 2768: 00 00 >> 2766: R_X86_64_32S current_task >> 276a: 48 83 b8 b8 0b 00 00 cmpq $0x0,0xbb8(%rax) >> 2771: 00 >> 2772: 74 1c je 2790 <syscall_trace_leave+0x50> >> 2774: 48 8b 73 50 mov 0x50(%rbx),%rsi >> 2778: 31 ff xor %edi,%edi >> 277a: 48 81 fe 00 f0 ff ff cmp $0xfffffffffffff000,%rsi >> 2781: 40 0f 96 c7 setbe %dil >> 2785: e8 00 00 00 00 callq 278a <syscall_trace_leave+0x4a> >> 2786: R_X86_64_PC32 __audit_syscall_exit-0x4 >> 278a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) >> 2790: 65 48 8b 04 25 00 00 mov %gs:0x0,%rax >> 2797: 00 00 >> 2795: R_X86_64_32S kernel_stack >> 2799: 48 8b 80 38 e0 ff ff mov -0x1fc8(%rax),%rax >> 27a0: a9 00 00 00 10 test $0x10000000,%eax >> 27a5: 74 71 je 2818 <syscall_trace_leave+0xd8> >> 27a7: 4c 8b 6b 50 mov 0x50(%rbx),%r13 >> 27ab: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) > > Here's the static_key branch > >> 27b0: eb 62 jmp 2814 <syscall_trace_leave+0xd4> >> 27b2: 80 3d 00 00 00 00 00 cmpb $0x0,0x0(%rip) # 27b9 <syscall_trace_leave+0x79> >> 27b4: R_X86_64_PC32 .data.unlikely-0x4 >> 27b9: 75 28 jne 27e3 <syscall_trace_leave+0xa3> >> 27bb: e8 00 00 00 00 callq 27c0 <syscall_trace_leave+0x80> >> 27bc: R_X86_64_PC32 .text.unlikely-0x4 > > Interesting that we have a "callq" to the next instruction. I think this is just unrelocated output, presumably from objdump -dr something.o. objdump -d vmlinux will give better output. --Andy, who got confused by exactly the same thing while debugging the vdso -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists