On Thu, 9 Jul 2026 14:22:23 +0000
Pu Hu <[email protected]> wrote:

> From: Pu Hu <[email protected]>
> 
> kprobe_fault_handler() currently treats any page fault taken while in
> KPROBE_HIT_SS or KPROBE_REENTER state as a kprobe single-step fault. This
> assumption does not hold: perf or tracing code may run from the debug
> exception path during the single-step window and take its own page fault.
> 
> When the fault is handled as a kprobe fault, the PC is rewritten to the
> probe address, corrupting the exception recovery context for the real
> fault. A typical reproducer is running perf with preemptirq tracepoints
> and dwarf callchains while a kprobe is installed on a frequently
> executed function.
> 
> Fix this in two layers:
> 
> 1. At function entry, bail out immediately for simulated kprobes
>    (ainsn.xol_insn == NULL), since they have no XOL slot and any fault
>    taken during their execution cannot be a single-step fault.
> 
> 2. For kprobes with an XOL slot, only handle the fault when the
>    faulting PC matches the XOL instruction address. Faults from any
>    other PC are left to the normal page fault handler.
> 
> This follows the same principle as the x86 fix in commit 6381c24cd6d5
> ("kprobes/x86: Fix page-fault handling logic").
> 
> Signed-off-by: Pu Hu <[email protected]>
> Signed-off-by: Hongyan Xia <[email protected]>

This looks good to me.

Reviewed-by: Masami Hiramatsu (Google) <[email protected]>

Thanks,

> ---
>  arch/arm64/kernel/probes/kprobes.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/arch/arm64/kernel/probes/kprobes.c 
> b/arch/arm64/kernel/probes/kprobes.c
> index 43a0361a8bf0..798e4b091d1a 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -282,9 +282,31 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, 
> unsigned int fsr)
>       struct kprobe *cur = kprobe_running();
>       struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>  
> +     /*
> +      * Simulated kprobes execute in the debug trap context and have no
> +      * XOL slot. Any page fault taken while a simulated kprobe is in
> +      * progress cannot have been caused by kprobe single-stepping and
> +      * must be left alone for the normal page fault handler, including
> +      * fixup_exception.
> +      */
> +     if (cur && !cur->ainsn.xol_insn)
> +             return 0;
> +
>       switch (kcb->kprobe_status) {
>       case KPROBE_HIT_SS:
>       case KPROBE_REENTER:
> +             /*
> +              * A page fault taken while in KPROBE_HIT_SS or
> +              * KPROBE_REENTER state is only attributable to kprobe
> +              * single-stepping if the faulting PC points to the
> +              * current kprobe's XOL instruction. If the fault occurred
> +              * elsewhere (e.g. in perf or tracing code invoked from the
> +              * debug exception path), leave it for the normal page fault
> +              * handler to process.
> +              */
> +             if (instruction_pointer(regs) != (unsigned 
> long)cur->ainsn.xol_insn)
> +                     break;
> +
>               /*
>                * We are here because the instruction being single
>                * stepped caused a page fault. We reset the current
> -- 
> 2.43.0
> 


-- 
Masami Hiramatsu (Google) <[email protected]>

Reply via email to