[RFC 1/3] arm64: kprobes: Do not handle non-XOL faults as kprobe faults

[Masami Hiramatsu (Google)]

On Mon, 6 Jul 2026 08:36:48 +0000
Pu Hu <hupu at transsion.com> wrote:

> From: Pu Hu <hupu at transsion.com>
> 
> kprobe_fault_handler() handles faults taken while kprobes is in
> KPROBE_HIT_SS or KPROBE_REENTER state as faults caused by the
> single-stepped instruction.
> 
> That assumption is not always true. While a kprobe is preparing or
> executing the out-of-line single-step instruction, other code may run
> in that window. For example, perf or trace code can be invoked from the
> debug exception path and may take a fault of its own. In that case the
> fault did not happen on the kprobe XOL instruction, but the kprobe fault
> handler may still try to recover it as a kprobe single-step fault.
> 
> This can corrupt the exception recovery flow and leave the real fault to
> be handled with a wrong PC. A typical reproducer is running simpleperf
> with preemptirq tracepoints and dwarf callchains while a kprobe is
> installed on a frequently executed kernel function.
> 
> Fix this by handling faults in KPROBE_HIT_SS/KPROBE_REENTER only when
> the faulting PC points at the current kprobe's XOL instruction. Faults
> from any other PC are left to the normal fault handling path.
> 
> This follows the same idea as the x86 fix in commit 6381c24cd6d5
> ("kprobes/x86: Fix page-fault handling logic").
> 
> Signed-off-by: Pu Hu <hupu at transsion.com>
> Signed-off-by: Hongyan Xia <hongyan.xia at transsion.com>
> ---
>  arch/arm64/kernel/probes/kprobes.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index 43a0361a8bf0..e4d2852ce2fb 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -285,6 +285,20 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
>  	switch (kcb->kprobe_status) {
>  	case KPROBE_HIT_SS:
>  	case KPROBE_REENTER:
> +		/*
> +		 * A fault taken while a kprobe is single-stepping is not
> +		 * necessarily caused by the instruction in the XOL slot. For
> +		 * example, tracing or perf code running in this window may take
> +		 * an unrelated fault.
> +		 *
> +		 * Handle the fault here only when the faulting PC is the XOL
> +		 * instruction of the current kprobe. Otherwise let the normal
> +		 * fault handling path deal with it.
> +		 */
> +		if (cur->ainsn.xol_insn &&
> +			instruction_pointer(regs) != (unsigned long)cur->ainsn.xol_insn)
> +			break;

Can you check Sashiko's comments[1]?

[1] https://sashiko.dev/#/patchset/20260706083636.159883-1-hupu%40transsion.com?part=1

It seems that it complains about simulated kprobe's case.
In that case, cur->ainsn.xol_insn == NULL. The simulation should be done
in the kprobe context (which is a debug trap). I'm not sure the arm64
can cause NMI in that context, but if it happens and causes a fault,
it may cause a problem.

So I think we can just ignore the fault on the simulated kprobes.

To ensure that, you can just add:

	if (cur && !cur->ainsn.xol_insn)
		return 0;

at the entry of this function. (and remove redundant cur->ainsn.xol_insn check)

Thank you,

> +
>  		/*
>  		 * We are here because the instruction being single
>  		 * stepped caused a page fault. We reset the current
> -- 
> 2.43.0
> 


-- 
Masami Hiramatsu (Google) <mhiramat at kernel.org>