lkml.org 
[lkml]   [2016]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Subject[PATCH] kprobes: fix race condition in __unregister_kprobe_top
Date
In the following case, it will trigger kernel panic:
1. register a kprobe for one function
2. register a jprobe for the same function (to make it easier to
reproduce, let the entry callback take a long time such as calling
mdelay)
3. trigger the function be called, and then unregister the jprobe
(before the entry callback calling jprobe_return)

The reason is that in __unregister_kprobe_top (unregister_jprobe)
the break_handler of the aggrprobe will be set NULL, but now the
entry callback may has been triggered (before jprobe_return), and
then in jprobe_return, it trigger int3/brk exception, in exception
handler, because the break_handler has been set NULL, it will not
setup_singlestep, and will return to the original instrucion...

To fix this bug, __unregister_kprobe_top call the synchronize_sched()
before clearing the handler.

Signed-off-by: Li Bin <huawei.libin@huawei.com>
---
kernel/kprobes.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index d10ab6b..5b5dd68 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1615,6 +1615,7 @@ static int __unregister_kprobe_top(struct kprobe *p)
*/
goto disarmed;
else {
+ synchronize_sched();
/* If disabling probe has special handlers, update aggrprobe */
if (p->break_handler && !kprobe_gone(p))
ap->break_handler = NULL;
--
1.7.1
\
 
 \ /
  Last update: 2016-04-20 03:21    [W:0.051 / U:0.888 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site