Re: [PATCH RESEND] entry: Fix seccomp bypass after ptrace with TSYNC

[Thomas Gleixner <tglx@kernel.org>]

On Thu, Jul 09 2026 at 15:30, Jinjie Ruan wrote:
> Sashiko review pointed out the following issue[1].
>
> If a thread is stopped in syscall_trace_enter() for ptrace, another
> thread can install a seccomp filter with SECCOMP_FILTER_FLAG_TSYNC
> (e.g., via seccomp_attach_filter()). This will successfully set
> SYSCALL_WORK_SECCOMP on the stopped thread, but syscall_trace_enter()
> evaluates a cached 'work' variable sampled on entry. Consequently,
> the subsequent check for SYSCALL_WORK_SECCOMP misses the newly
> assigned flag, and the filter is silently bypassed.
>
> This race condition could allow an unprivileged process to execute
> a prohibited system call (e.g., execve) that the newly installed filter
> was intended to block, especially since the tracer might have modified
> the system call number during the ptrace stop.
>
> Fix this by replacing the cached seccomp check with a call to
> seccomp_permit_syscall(), which re-reads the thread's up-to-date
> TIF_SECCOMP flag and thus correctly observes the flag if it was set
> during the ptrace stop.

No, we are not doing this unconditionally.

Thanks,

        tglx
---
--- a/include/linux/entry-common.h
+++ b/include/linux/entry-common.h
@@ -98,6 +98,8 @@ static __always_inline long syscall_trac
 		ret = arch_ptrace_report_syscall_entry(regs);
 		if (ret || (work & SYSCALL_WORK_SYSCALL_EMU))
 			return -1L;
+		/* ptrace might have changed work flags */
+		work = READ_ONCE(current_thread_info()->syscall_work);
 	}
 
 	/* Do seccomp after ptrace, to catch any tracer changes. */