Hi Andi and Andrew,
I found a bug of kprobes on x86_64.
I attached the fix of this bug.
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.
Regards,
Satoshi Oshima
Hitachi Computer Product (America) Inc.
----------------------------------------------
diff -Narup linux-2.6.17-rc3-mm1.orig/arch/x86_64/kernel/kprobes.c x86_64_bugifx/arch/x86_64/kernel/kprobes.c
--- linux-2.6.17-rc3-mm1.orig/arch/x86_64/kernel/kprobes.c 2006-05-04 12:34:44.000000000 -0400
+++ x86_64_bugifx/arch/x86_64/kernel/kprobes.c 2006-05-12 16:02:35.000000000 -0400
@@ -514,13 +514,13 @@ static void __kprobes resume_execution(s
*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;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
