From: Yiqi Sun <sunyiqixm@gmail•com>
To: will@kernel•org
Cc: catalin.marinas@arm•com, kees@kernel•org,
keno@juliacomputing•com, linux-arm-kernel@lists•infradead.org,
linux-kernel@vger•kernel.org, luis.machado@linaro•org,
mark.rutland@arm•com, rmk+kernel@armlinux•org.uk,
ruanjinjie@huawei•com, sunyiqixm@gmail•com
Subject: Re: Re: [PATCH] fix: arm64: syscall: use live x0 for syscall_get_arguments() arg0
Date: Wed, 3 Jun 2026 17:07:30 +0800 [thread overview]
Message-ID: <20260603090730.16960-1-sunyiqixm@gmail.com> (raw)
In-Reply-To: <ah1-fmV1VcN3cKto@willie-the-truck>
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
prev parent reply other threads:[~2026-06-03 9:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-29 6:54 [PATCH] fix: arm64: syscall: use live x0 for syscall_get_arguments() arg0 Yiqi Sun
2026-06-01 12:43 ` Will Deacon
2026-06-03 9:07 ` Yiqi Sun [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260603090730.16960-1-sunyiqixm@gmail.com \
--to=sunyiqixm@gmail$(echo .)com \
--cc=catalin.marinas@arm$(echo .)com \
--cc=kees@kernel$(echo .)org \
--cc=keno@juliacomputing$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=luis.machado@linaro$(echo .)org \
--cc=mark.rutland@arm$(echo .)com \
--cc=rmk+kernel@armlinux$(echo .)org.uk \
--cc=ruanjinjie@huawei$(echo .)com \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox