CVE-2026-68171: arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates

In the Linux kernel, the following vulnerability has been resolved:

arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates

When seccomp support was originally added to arm64 in a1ae65b21941 ("arm64: add seccomp support"), seccomp was erroneously called before the ptrace syscall-enter-stop and therefore the tracer could trivially manipulate the syscall register state after the seccomp check had passed. This was subsequently fixed in a5cd110cb836 ("arm64/ptrace: run seccomp after ptrace") by moving the seccomp check after the tracer has run. Unfortunately, a decade later, that fix has been reported to be incomplete.

On arm64, both the first argument to a syscall and its eventual return value are allocated to register x0. In order to facilitate syscall restarting and querying of syscall arguments on the syscall exit path, the original value of x0 is stashed in 'struct ptregs::origx0' early during the syscall entry path and is returned for the first argument by syscallgetarguments(). Unlike 32-bit Arm, this stashed value is not directly exposed via ptrace() and so changes to register x0 made by the tracer on a syscall-enter-stop are not reflected in 'origx0'. This means that seccomp, syscall tracepoints and audit can observe a stale value for the register compared to the argument that will be observed by the actual syscall.

Re-sync 'origx0' from x0 on the syscall entry path following a potential ptrace stop (i.e. PTRACEEVENTMSGSYSCALLENTRY or SECCOMPRETTRACE). This behaviour is limited to native tasks (because compat tasks expose 'origr0' to ptrace) where the syscall is not being skipped (because x0 is updated to hold the return value of -ENOSYS in that case).