Re: [PATCH] ARM: ptrace: keep ARM_ORIG_r0 consistent with ARM_r0 after ptrace writes

[Russell King]

On Sat, Jul 25, 2026 at 05:14:52PM +0800, Jinjie Ruan wrote:
> When ptrace modifies r0 during a syscall-entry stop via PTRACE_SETREGS or
> PTRACE_POKEUSR, ARM_ORIG_r0 is not updated.  This causes seccomp filters
> and tracepoints to read stale arguments, which disagree with the actual
> value dispatched by the kernel.  This is particularly critical for the
> SECCOMP_RET_TRACE re-evaluation path.
> 
> Fix it by synchronizing ARM_ORIG_r0 after every arch-level ptrace register
> write.  The update safely skips syscall-exit stops (where r0 holds the
> return value) and NO_SYSCALL states to avoid corrupting non-syscall
> contexts. And use ARM_ORIG_r0 in audit_syscall_entry to fix data
> inconsistency with seccomp/tracepoints

ARM_ORIG_r0 is intentionally not always the same as ARM_r0, just as
orig_eax is not always the same as eax in x86. These exist to allow
syscall restart as ARM_r0 / eax will be overwritten when a syscall
returns. I don't see arch/x86/kernel/ptrace.c::putreg32() needing
this kind of fixup, so why does ARM?

ARM_ORIG_r0 is set to the value of ARM_r0 when a syscall is entered,
otherwise it is set to ~0 as for other exception cases, the value is
meaningless (there is no syscall restart in that path.)

If one changes both ARM_ORIG_r0 and ARM_r0 during the syscall exit
path to e.g. -ERESTARTSYS and then raises a signal against the user
program, then is it not possible that do_signal() to then see that
case, and as regs->ARM_ORIG_r0 would now also contain -ERESTARTSYS,
call the syscall with the first argument set to -ERESTARTSYS rather
than the user's actual value?

Userspace has full access to both ARM_r0 and ARM_ORIG_r0, and can
decide what it wants to do in the same way that userspace has
access to eax and orig_eax on x86.

Please check how this is handled on x86.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!