Re: CVE-2026-89603: entry: Fix seccomp bypass after ptrace with TSYNC

[Kees Cook]

On Fri, Sep 11, 2026 at 09:44:52PM +0200, Greg Kroah-Hartman wrote:
> 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.

I'm disputing this one: please reject CVE-2026-89603. The fix is a fine
consistency change, but the flaw gave neither the tracer nor the tracee
anything they didn't already have.

The missed check only affects a thread's first filter. Once a thread has
any filter, seccomp_run_filters() loads the current filter list when it
runs, so a filter synced during the ptrace stop applies anyway. So the
thread entered the syscall with no filter at all, and stopped under a
tracer that controlled it. That tracer could already have made it run
any syscall before the filter existed, or simply refused its seccomp()
call. No syscall gets past a filter that was in place when the syscall
started.

The same window exists without ptrace: TSYNC can land just after
syscall entry reads the work flags, and the syscall in flight runs
unfiltered. TSYNC has never applied to a syscall a thread has already
entered, only to its next one.

Sorry I missed this when the CVE originally went out! Thank you to
Oleg for calling this to my attention on the original patch's thread:
https://lore.kernel.org/all/as9Jqi5BvSZWfxj8@xxxxxxxxxx/ :)

-Kees

-- 
Kees Cook