Re: Re: [PATCH] fix: arm64: syscall: use live x0 for syscall_get_arguments() arg0

[Will Deacon]

On Wed, Jun 03, 2026 at 05:07:30PM +0800, Yiqi Sun wrote:
> On Mon, 1 Jun 2026 13:43:42 +0100, Well wrote:
> > On Fri, May 29, 2026 at 02:54:44PM +0800, Yiqi Sun wrote:
> > > On arm64, seccomp obtains syscall arguments via syscall_get_arguments(),
> > > where arg0 is currently read from regs->orig_x0. However, the syscall
> > > wrapper consumes live arguments from regs->regs[0..5].
> > > 
> > > A ptracer can modify x0 on syscall-enter stop before seccomp runs,
> > > but cannot update orig_x0 through that interface. This can
> > > leave seccomp checking stale arg0 while the syscall executes with updated
> > > live x0, allowing seccomp bypass when filters depend on arg0.
> > > 
> > > Make syscall_get_arguments() read arg0 from regs->regs[0], matching the
> > > actual dispatch arguments and removing this desynchronization.
> > > 
> > > Fixes: f27bb139c387 ("arm64: Miscellaneous library functions")
> > > Signed-off-by: Yiqi Sun <sunyiqixm@xxxxxxxxx>
> > > ---
> > >  arch/arm64/include/asm/syscall.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h
> > > index 5e4c7fc44f73..4bdb4d3ce2b4 100644
> > > --- a/arch/arm64/include/asm/syscall.h
> > > +++ b/arch/arm64/include/asm/syscall.h
> > > @@ -81,7 +81,7 @@ static inline void syscall_get_arguments(struct task_struct *task,
> > >  					 struct pt_regs *regs,
> > >  					 unsigned long *args)
> > >  {
> > > -	args[0] = regs->orig_x0;
> > > +	args[0] = regs->regs[0];
> > >  	args[1] = regs->regs[1];
> > >  	args[2] = regs->regs[2];
> > >  	args[3] = regs->regs[3];
> > > -- 
> > > 2.34.1
> > 
> > Hrm, this looks like a long-standing issue and I'm pretty nervous about
> > changing it :/
> > 
> > How did you spot it?
> 
> I share your concern here, and I’m trying to be very careful with any
> behavior change.
> 
> I spotted this while comparing seccomp+ptrace ordering across arches.
> I had previously looked at x86/x86_64 (including the seccomp/ptrace
> ordering fix from more than 10 years ago), and then checked whether
> other arches like arm64 had the same issue.
> 
> > A quick look at the code suggests we have a similar issue with
> > audit_syscall_entry(), so if we take your patch here then it will silently
> > introduce a behavioural change to this guy:
> > 
> > https://lore.kernel.org/all/20260320102620.1336796-5-ruanjinjie@xxxxxxxxxx/
> > 
> > I also notice that the compat ptrace interface allows 'orig_x0' to be
> > set -- could that cause issues with things like syscall_rollback()?
> > Will
> 
> You are right that on arm64, audit_syscall_entry() still takes arg0
> from orig_x0, so taking only this seccomp fix would diverge seccomp
> and audit semantics.
> 
> I also checked syscall_rollback(): on arm64 it restores regs[0] from
> orig_x0, and orig_x0 is captured at syscall entry before the ptrace
> syscall-stop hook. So rollback normally returns to the syscall-entry
> state (i.e. pre-ptrace argument value), which does not look like a new
> security issue by itself. compat ptrace can explicitly write orig_x0,
> but that is existing tracer-controlled behavior and does not, by itself,
> cross a new security boundary introduced by this patch.
> 
> If you agree, I can send a follow-up later so seccomp/audit stay consistent.

Yes, please send a v2 that fixes audit at the same time.

Will