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@gmail.com>
---
 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

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@gmail.com>
> ---
>  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?

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@huawei.com/

I also notice that the compat ptrace interface allows 'orig_x0' to be
set -- could that cause issues with things like syscall_rollback()?

Will

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@gmail.com>
> > ---
> >  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@huawei.com/
> 
> 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.

Yiqi Sun