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

From: Thomas Gleixner

Date: Sun Jul 12 2026 - 06:09:04 EST


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. */