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

[Kees Cook <kees@kernel.org>]

On Wed, Oct 14, 2026 at 11:21:46AM +0200, Oleg Nesterov wrote:
> I agree with this patch, but SECCOMP_FILTER_FLAG_TSYNC can also happen
> after syscall_trace_enter() re-reads ->syscall_work ?
>
> And this race is possible even without ptrace, SECCOMP_FILTER_FLAG_TSYNC
> from another thread can happen after syscall_enter_from_user_mode_work()
> reads ->syscall_work ?

Right, and that's expected: TSYNC has never covered a syscall a thread
has already entered; the filter applies from the thread's next syscall.

It also only matters for a thread's first filter. Once SYSCALL_WORK_SECCOMP
is set, seccomp_run_filters() loads current->seccomp.filter when it runs,
so a thread that already has a filter sees a newly synced one even with
stale work flags.

> I think we don't really care, but I don't understand the security concerns.
> If debugger controls the process before it installs the seccomp filters, it
> can simply nack sys_seccomp().
>
> In short, does CVE-2026-89603 make real sense?

I don't think it does. For the missed check to matter, the thread had
no filter when it entered the syscall, and the tracer had it stopped
there. That tracer could already make it run any syscall before the
filter existed, or, as you say, refuse the seccomp() call. Nothing gets
past a filter that was in place when the syscall started. I'll ask
the CVE team to reject it.

The patch is still right as a consistency fix: seccomp runs after
ptrace so it checks what the tracer left. arm64 re-tests the flag after
the ptrace stop, as powerpc, riscv, and s390 did before they moved to
generic entry.

I've sent a selftest for the ptrace case, based on Jinjie's reproducer:
https://lore.kernel.org/all/20261015161348.i.779-kees@kernel.org/

-Kees

-- 
Kees Cook