Re: [PATCH v16 05/18] arm64: ptrace: Expand secure_computing() in place

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Open-coding the seccomp check using a cached `flags` variable creates a Time-of-Check to Time-of-Use (TOCTOU) vulnerability during ptrace stops, allowing a seccomp filter installed via TSYNC to be bypassed.
--

commit 138e96f2aef98ac6348b34ceeb3157f77bd0f2f7
Author: Jinjie Ruan <ruanjinjie@huawei.com>

arm64: ptrace: Expand secure_computing() in place

This commit refactors syscall_trace_enter() by open-coding the seccomp
check to align with the generic entry framework. It explicitly checks
the flags parameter for _TIF_SECCOMP instead of calling the wrapper.

> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index 863083de37c37..30df515528e8f 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -2420,8 +2420,10 @@ int syscall_trace_enter(struct pt_regs *regs, unsigned long flags)
[ ... ]
>  	/* Do the secure computing after ptrace; failures should be fast. */
> -	if (!secure_computing())
> -		return NO_SYSCALL;
> +	if (flags & _TIF_SECCOMP) {
> +		if (!__secure_computing())
> +			return NO_SYSCALL;
> +	}

[Severity: High]
Does checking the cached 'flags' argument here instead of dynamically
reading the thread flags create a race condition?

If the current thread stops for ptrace earlier in syscall_trace_enter(),
and another thread installs a filter via seccomp with
SECCOMP_FILTER_FLAG_TSYNC while this thread is stopped, the newly set
_TIF_SECCOMP flag wouldn't be reflected in the local 'flags' variable.

Could this allow an unprivileged process to bypass a newly installed
seccomp filter for the current syscall, especially since the tracer might
modify the syscall number (e.g., to execve) during the ptrace stop?

As an additional detail, the generic entry code in include/linux/entry-common.h 
seems to exhibit the same pattern by checking a cached 'work' variable passed 
into syscall_trace_enter().

>  
>  	/* Either of the above might have changed the syscall number */
>  	syscall = syscall_get_nr(current, regs);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629130616.642022-1-ruanjinjie@huawei.com?part=5