[PATCH v2] arm64: ptrace: use live x0 for seccomp and audit after ptrace

[Will Deacon]

On Tue, Jul 14, 2026 at 11:20:20AM +0800, Jinjie Ruan wrote:
> 
> 
> On 7/13/2026 10:07 PM, Will Deacon wrote:
> > On Mon, Jul 13, 2026 at 03:49:18PM +0800, Jinjie Ruan wrote:
> >> On 7/1/2026 1:29 AM, Catalin Marinas wrote:
> >>> I think we need to keep orig_x0 as our original arg0 throughout the
> >>> kernel and just fix the tracer path to sync it on the syscall entry. It
> >>> doesn't unclutter the code but it shouldn't break the ABI either (unless
> >>> someone relied on the ptrace change x0 and not being noticed by
> >>> seccomp). Something like below:
> >>>
> >>> ----------------8<-----------------------------
> >>> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> >>> index 4d08598e2891..cd21b301e154 100644
> >>> --- a/arch/arm64/kernel/ptrace.c
> >>> +++ b/arch/arm64/kernel/ptrace.c
> >>> @@ -2417,6 +2417,18 @@ int syscall_trace_enter(struct pt_regs *regs)
> >>>  		ret = report_syscall_entry(regs);
> >>>  		if (ret || (flags & _TIF_SYSCALL_EMU))
> >>>  			return NO_SYSCALL;
> >>> +		/*
> >>> +		 * Keep orig_x0 authoritative so that seccomp (via
> >>> +		 * syscall_get_arguments()), audit and the restart path all
> >>> +		 * see the same first argument the syscall is dispatched with,
> >>> +		 * even if it has been updated by a tracer. Skip this for
> >>> +		 * NO_SYSCALL (set either by the user or the tracer) as
> >>> +		 * regs[0] holds the return value (see the comment in
> >>> +		 * el0_svc_common()). For compat, orig_r0 is provided directly
> >>> +		 * through GPR index 17.
> >>> +		 */
> >>> +		if (!is_compat_task() && regs->syscallno != NO_SYSCALL)
> >>> +			regs->orig_x0 = regs->regs[0];
> >>
> >> Can we place this fix in report_syscall_entry()? The generic entry
> >> framework has already reserved the function
> >> arch_ptrace_report_syscall_permit_entry() for architecture-specific
> >> customization, so switching to it might be more convenient.
> > 
> > Hmm, your comment prompted me to look at this some more and now I'm
> > unsure that the seccomp handling is correct, even with the fix above.
> 
> Hi Will,
> 
> It seems that this issue can be reproduced itself and Catalin's patch
> can fix the original question.

I'm not disputing that it fixes the reported issue, but I don't think
it's complete.

> I used DeepSeek to help write the following test method and script,
> which can successfully reproduce the issue.

I also have similar testcases for this, thanks.

I'll send a patch shortly.

Will