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

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

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

entry: Fix seccomp bypass after ptrace with TSYNC

Sashiko review pointed out the following issue.

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 re-reading the syscall_work flags after ptrace handling,
so that any new SYSCALL_WORK_SECCOMP flag set by another thread via
TSYNC during the ptrace stop is observed before the subsequent
seccomp check.

The Linux kernel CVE team has assigned CVE-2026-89603 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.9 with commit 142781e108b13b2b0e8f035cfb5bfbbc8f14d887 and fixed in 6.18.51 with commit 459f33f82864723a7fa366cf1091d9c6c893b6b2
	Issue introduced in 5.9 with commit 142781e108b13b2b0e8f035cfb5bfbbc8f14d887 and fixed in 7.2.4 with commit ab4647459098a43e9d6fdb860836f08c962f3774
	Issue introduced in 5.9 with commit 142781e108b13b2b0e8f035cfb5bfbbc8f14d887 and fixed in 7.3-rc1 with commit 4a3591287fb7f808e209b4974ed337f609a2006b

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-89603
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	include/linux/entry-common.h


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/459f33f82864723a7fa366cf1091d9c6c893b6b2
	https://git.kernel.org/stable/c/ab4647459098a43e9d6fdb860836f08c962f3774
	https://git.kernel.org/stable/c/4a3591287fb7f808e209b4974ed337f609a2006b

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