Techwizz/kernel-fxtec-pro1x
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

[PATCH] kprobes: bad manipulation of 2 byte opcode on x86_64

Browse source 
Problem:

If we put a probe onto a callq instruction and the probe is executed,
kernel panic of Bad RIP value occurs.

Root cause:

If resume_execution() found 0xff at first byte of p->ainsn.insn, it must
check the _second_ byte.  But current resume_execution check _first_ byte
again.

I changed it checks second byte of p->ainsn.insn.

Kprobes on i386 don't have this problem, because the implementation is a
little bit different from x86_64.

Cc: Andi Kleen <ak@muc.de>
Signed-off-by: Satoshi Oshima <soshima@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This commit is contained in:
Satoshi Oshima 2006-05-20 15:00:21 -07:00 committed by Linus Torvalds
parent be0d03f1c3
commit dc49e3445a
1 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
arch/x86_64/kernel/kprobes.c
View file

@ -514,13 +514,13 @@ static void __kprobes resume_execution(struct kprobe *p,
*tos = orig_rip + (*tos - copy_rip);
break;
case 0xff:
if ((*insn & 0x30) == 0x10) {
if ((insn[1] & 0x30) == 0x10) {
/* call absolute, indirect */
/* Fix return addr; rip is correct. */
next_rip = regs->rip;
*tos = orig_rip + (*tos - copy_rip);
} else if (((*insn & 0x31) == 0x20) || /* jmp near, absolute indirect */
((*insn & 0x31) == 0x21)) { /* jmp far, absolute indirect */
} else if (((insn[1] & 0x31) == 0x20) || /* jmp near, absolute indirect */
((insn[1] & 0x31) == 0x21)) { /* jmp far, absolute indirect */
/* rip is correct. */
next_rip = regs->rip;
}