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

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@redhat.com/ :)

-Kees

-- 
Kees Cook

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

[Oleg Nesterov]

On 10/15, Kees Cook wrote:
>
> 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.

Thanks Kees!

I fully agree with both points. The patch is fine, but it doesn't fix
any security problem.

Oleg.

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

[Greg Kroah-Hartman]

On Thu, Oct 15, 2026 at 06:34:13PM +0200, Oleg Nesterov wrote:
> On 10/15, Kees Cook wrote:
> >
> > 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.
> 
> Thanks Kees!
> 
> I fully agree with both points. The patch is fine, but it doesn't fix
> any security problem.

Now rejected, thanks for the review and letting us know!

greg k-h