2022-08-02 06:14:51

by Masami Hiramatsu

Subject: [PATCH] x86/kprobes: Fix to update kcb status flag after singlestepping

From: Masami Hiramatsu (Google) <[email protected]>

Fix kprobes to update kcb (kprobes control block) status flag to
KPROBE_HIT_SSDONE even if the kp->post_handler is not set.
This may cause a kernel panic if another int3 user runs right
after kprobes because kprobe_int3_handler() misunderstands the
int3 is kprobe's single stepping int3.

Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step")
Reported-by: Daniel Müller <[email protected]>
Tested-by: Daniel Müller <[email protected]>
Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/all/20220727210136.jjgc3lpqeq42yr3m@muellerd-fedora-PC2BDTX9
---
arch/x86/kernel/kprobes/core.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 7c4ab8870da4..74167dc5f55e 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -814,16 +814,20 @@ set_current_kprobe(struct kprobe *p, struct pt_regs *regs,
static void kprobe_post_process(struct kprobe *cur, struct pt_regs *regs,
struct kprobe_ctlblk *kcb)
{
- if ((kcb->kprobe_status != KPROBE_REENTER) && cur->post_handler) {
- kcb->kprobe_status = KPROBE_HIT_SSDONE;
- cur->post_handler(cur, regs, 0);
- }
-
/* Restore back the original saved kprobes variables and continue. */
- if (kcb->kprobe_status == KPROBE_REENTER)
+ if (kcb->kprobe_status == KPROBE_REENTER) {
+ /* This will restore both kcb and current_kprobe */
restore_previous_kprobe(kcb);
- else
+ } else {
+ /*
+ * Always update the kcb status because
+ * reset_curent_kprobe() doesn't update kcb.
+ */
+ kcb->kprobe_status = KPROBE_HIT_SSDONE;
+ if (cur->post_handler)
+ cur->post_handler(cur, regs, 0);
reset_current_kprobe();
+ }
}
NOKPROBE_SYMBOL(kprobe_post_process);

2022-08-02 15:11:32

by Steven Rostedt

Subject: Re: [PATCH] x86/kprobes: Fix to update kcb status flag after singlestepping

On Tue, 2 Aug 2022 15:04:16 +0900
"Masami Hiramatsu (Google)" <[email protected]> wrote:

> From: Masami Hiramatsu (Google) <[email protected]>
>
> Fix kprobes to update kcb (kprobes control block) status flag to
> KPROBE_HIT_SSDONE even if the kp->post_handler is not set.
> This may cause a kernel panic if another int3 user runs right
> after kprobes because kprobe_int3_handler() misunderstands the
> int3 is kprobe's single stepping int3.
>
> Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step")
> Reported-by: Daniel Müller <[email protected]>
> Tested-by: Daniel Müller <[email protected]>
> Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
> Cc: [email protected]
> Link: https://lore.kernel.org/all/20220727210136.jjgc3lpqeq42yr3m@muellerd-fedora-PC2BDTX9
> ---

Acked-by: Steven Rostedt (Google) <[email protected]>

I guess this will go through the tip tree?

-- Steve

2022-08-02 17:39:51

by Ingo Molnar

Subject: Re: [PATCH] x86/kprobes: Fix to update kcb status flag after singlestepping

* Steven Rostedt <[email protected]> wrote:

> On Tue, 2 Aug 2022 15:04:16 +0900
> "Masami Hiramatsu (Google)" <[email protected]> wrote:
>
> > From: Masami Hiramatsu (Google) <[email protected]>
> >
> > Fix kprobes to update kcb (kprobes control block) status flag to
> > KPROBE_HIT_SSDONE even if the kp->post_handler is not set.
> > This may cause a kernel panic if another int3 user runs right
> > after kprobes because kprobe_int3_handler() misunderstands the
> > int3 is kprobe's single stepping int3.
> >
> > Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step")
> > Reported-by: Daniel M?ller <[email protected]>
> > Tested-by: Daniel M?ller <[email protected]>
> > Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
> > Cc: [email protected]
> > Link: https://lore.kernel.org/all/20220727210136.jjgc3lpqeq42yr3m@muellerd-fedora-PC2BDTX9
> > ---
>
> Acked-by: Steven Rostedt (Google) <[email protected]>
>
> I guess this will go through the tip tree?

Yeah, it's already in tip:perf/urgent.

Thanks,

Ingo