linux-kernel - Re: ptrace: gpf in syscall_trace

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]

Date:	Wed, 07 May 2014 11:52:35 -0400
From:	Sasha Levin <sasha.levin@...cle.com>
To:	Steven Rostedt <rostedt@...dmis.org>,
	Oleg Nesterov <oleg@...hat.com>
CC:	roland@...hat.com, LKML <linux-kernel@...r.kernel.org>,
	Dave Jones <davej@...hat.com>
Subject: Re: ptrace: gpf in syscall_trace_enter

On 05/07/2014 11:49 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().
>>
>>> [ 6897.628729] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>>> [ 6897.629654] Dumping ftrace buffer:
>>> [ 6897.630034]    (ftrace buffer empty)
>>> [ 6897.630034] Modules linked in:
>>> [ 6897.630034] CPU: 24 PID: 23736 Comm: trinity-c148 Tainted: G    B         3.15.0-rc4-next-20140506-sasha-00021-gc164334-dirty #447
>>> [ 6897.630034] task: ffff88002a870000 ti: ffff88000ef04000 task.ti: ffff88000ef04000
>>> [ 6897.630034] RIP: syscall_trace_leave (include/trace/events/syscalls.h:42 arch/x86/kernel/ptrace.c:1517)
> 
> Thanks for sending the objdump, but then I just realized that this dump
> doesn't have the actual RIP. It just says syscall_trace_leave, without
> even giving me the offset.
> 
> As the objdump is just of the object files and not the vmlinux, I would
> need the offset from syscall_trace_leave of the RIP.

    2803:	41 ff 14 24          	callq  *(%r12)  <=== Here
    2807:	49 83 c4 10          	add    $0x10,%r12
    280b:	49 83 3c 24 00       	cmpq   $0x0,(%r12)


Thanks,
Sasha
--
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/