Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1590125
| From | tip-bot for Masami Hiramatsu <tipbot@zytor.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | [tip:perf/urgent] kprobes/x86: Fix kernel panic when certain exception-handling addresses are probed |
| Date | 2017-03-01 10:20 +0100 |
| Message-ID | <tg8Av-Y7-21@gated-at.bofh.it> (permalink) |
| References | <tfU4p-7JC-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Commit-ID: 75013fb16f8484898eaa8d0b08fed942d790f029
Gitweb: http://git.kernel.org/tip/75013fb16f8484898eaa8d0b08fed942d790f029
Author: Masami Hiramatsu <mhiramat@kernel.org>
AuthorDate: Wed, 1 Mar 2017 01:23:24 +0900
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 1 Mar 2017 09:56:13 +0100
kprobes/x86: Fix kernel panic when certain exception-handling addresses are probed
Fix to the exception table entry check by using probed address
instead of the address of copied instruction.
This bug may cause unexpected kernel panic if user probe an address
where an exception can happen which should be fixup by __ex_table
(e.g. copy_from_user.)
Unless user puts a kprobe on such address, this doesn't
cause any problem.
This bug has been introduced years ago, by commit:
464846888d9a ("x86/kprobes: Fix a bug which can modify kernel code permanently").
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 464846888d9a ("x86/kprobes: Fix a bug which can modify kernel code permanently")
Link: http://lkml.kernel.org/r/148829899399.28855.12581062400757221722.stgit@devbox
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
arch/x86/kernel/kprobes/common.h | 2 +-
arch/x86/kernel/kprobes/core.c | 6 +++---
arch/x86/kernel/kprobes/opt.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/kprobes/common.h b/arch/x86/kernel/kprobes/common.h
index c6ee63f..d688826 100644
--- a/arch/x86/kernel/kprobes/common.h
+++ b/arch/x86/kernel/kprobes/common.h
@@ -67,7 +67,7 @@
#endif
/* Ensure if the instruction can be boostable */
-extern int can_boost(kprobe_opcode_t *instruction);
+extern int can_boost(kprobe_opcode_t *instruction, void *addr);
/* Recover instruction if given address is probed */
extern unsigned long recover_probed_instruction(kprobe_opcode_t *buf,
unsigned long addr);
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 520b8df..88b3c94 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -166,12 +166,12 @@ NOKPROBE_SYMBOL(skip_prefixes);
* Returns non-zero if opcode is boostable.
* RIP relative instructions are adjusted at copying time in 64 bits mode
*/
-int can_boost(kprobe_opcode_t *opcodes)
+int can_boost(kprobe_opcode_t *opcodes, void *addr)
{
kprobe_opcode_t opcode;
kprobe_opcode_t *orig_opcodes = opcodes;
- if (search_exception_tables((unsigned long)opcodes))
+ if (search_exception_tables((unsigned long)addr))
return 0; /* Page fault may occur on this address. */
retry:
@@ -416,7 +416,7 @@ static int arch_copy_kprobe(struct kprobe *p)
* __copy_instruction can modify the displacement of the instruction,
* but it doesn't affect boostable check.
*/
- if (can_boost(p->ainsn.insn))
+ if (can_boost(p->ainsn.insn, p->addr))
p->ainsn.boostable = 0;
else
p->ainsn.boostable = -1;
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 3d1bee9..3e7c6e5 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -178,7 +178,7 @@ static int copy_optimized_instructions(u8 *dest, u8 *src)
while (len < RELATIVEJUMP_SIZE) {
ret = __copy_instruction(dest + len, src + len);
- if (!ret || !can_boost(dest + len))
+ if (!ret || !can_boost(dest + len, src + len))
return -EINVAL;
len += ret;
}
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
kprobes vs __ex_table[] Peter Zijlstra <peterz@infradead.org> - 2017-02-23 19:40 +0100
Re: kprobes vs __ex_table[] Masami Hiramatsu <mhiramat@kernel.org> - 2017-02-24 02:10 +0100
Re: kprobes vs __ex_table[] Peter Zijlstra <peterz@infradead.org> - 2017-02-24 10:30 +0100
Re: kprobes vs __ex_table[] Masami Hiramatsu <mhiramat@kernel.org> - 2017-02-24 17:40 +0100
Re: kprobes vs __ex_table[] Peter Zijlstra <peterz@infradead.org> - 2017-02-24 18:50 +0100
[RFC PATCH 1/2] kprobes/x86: Use probe_kernel_read instead of memcpy Masami Hiramatsu <mhiramat@kernel.org> - 2017-02-27 17:20 +0100
[RFC PATCH 2/2] kprobes/x86: Exit single-stepping before trying fixup_exception Masami Hiramatsu <mhiramat@kernel.org> - 2017-02-27 17:20 +0100
Re: [RFC PATCH 2/2] kprobes/x86: Exit single-stepping before trying fixup_exception Masami Hiramatsu <mhiramat@kernel.org> - 2017-03-02 00:40 +0100
[RFC PATCH 0/2] kprobes/x86: Handle probing on ex_table cases Masami Hiramatsu <mhiramat@kernel.org> - 2017-02-27 17:20 +0100
Re: kprobes vs __ex_table[] Masami Hiramatsu <mhiramat@kernel.org> - 2017-02-28 17:30 +0100
[PATCH] [BUGFIX] kprobes/x86: Fix to check __ex_table entry by probed address Masami Hiramatsu <mhiramat@kernel.org> - 2017-02-28 18:50 +0100
[tip:perf/urgent] kprobes/x86: Fix kernel panic when certain exception-handling addresses are probed tip-bot for Masami Hiramatsu <tipbot@zytor.com> - 2017-03-01 10:20 +0100
csiph-web