CVE-2026-89603: entry: Fix seccomp bypass after ptrace with TSYNC
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 syscalltraceenter() for ptrace, another thread can install a seccomp filter with SECCOMPFILTERFLAGTSYNC (e.g., via seccompattachfilter()). This will successfully set SYSCALLWORKSECCOMP on the stopped thread, but syscalltraceenter() evaluates a cached 'work' variable sampled on entry. Consequently, the subsequent check for SYSCALLWORKSECCOMP 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 syscallwork flags after ptrace handling, so that any new SYSCALLWORKSECCOMP flag set by another thread via TSYNC during the ptrace stop is observed before the subsequent seccomp check.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch entry: Fix seccomp bypass after ptrace with TSYNC - Compensating control
For systems where this issue is present, avoid using SECCOMP_FILTER_FLAG_TSYNC with seccomp filters (it can allow a TSYNC race with ptrace stop to bypass the intended blocking of prohibited system calls such as execve).
Event History
Frequently Asked Questions
What conditions are required for exploitation?
A thread must be stopped in syscall_trace_enter() for ptrace while another thread installs a seccomp filter using SECCOMP_FILTER_FLAG_TSYNC. The stopped thread can then miss the newly applied seccomp work flag and execute a system call the filter was meant to prohibit.
Who can exploit this issue?
The description states that an unprivileged process could exploit the race. Exploitation depends on coordinating ptrace handling and a thread-synchronized seccomp filter installation within the process.
How can I tell whether a system is exposed?
Exposure depends on whether the running Linux kernel includes the fix that re-reads syscall_work flags after ptrace handling. Systems using ptrace together with seccomp filters installed via SECCOMP_FILTER_FLAG_TSYNC are the relevant configurations to review.
What is the practical impact of a successful race?
A system call prohibited by a newly installed seccomp filter can be executed without the filter being applied to that call. The description specifically identifies execve as an example, particularly when a tracer changes the system call number during the ptrace stop.