CVE-2026-89603 in Linux
Summary
by MITRE • 09/12/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/12/2026
The Linux kernel contains a critical race condition vulnerability within the system call tracing and secure computing subsystems that allows for the bypass of security filters under specific multi-threaded conditions. This flaw arises from an inconsistency in how thread-local work flags are sampled and evaluated during the entry path of system calls when ptrace is actively involved. The core issue lies in the timing of flag evaluation relative to state changes initiated by other threads, specifically those related to seccomp filter attachment with the TSYNC synchronization option.
When a process utilizes ptrace to trace another thread, that traced thread may be stopped at various points during its execution, including within syscall_trace_enter(). During this paused state, an unprivileged or malicious actor controlling another thread in the same process can invoke seccomp_attach_filter() with the SECCOMP_FILTER_FLAG_TSYNC flag. This operation is designed to synchronize and apply a new security filter across all threads in the process group. The kernel correctly updates the internal SYSCALL_WORK_SECCOMP work structure for the stopped thread, marking it as subject to the new restrictions. However, the vulnerability occurs because syscall_trace_enter() relies on a cached copy of these work flags that was sampled earlier upon entry into the system call path. Because this snapshot is taken before the ptrace stop and subsequent filter installation by another thread, the kernel fails to recognize the newly applied seccomp constraints when it performs its security checks later in the execution flow.
This race condition effectively creates a window of opportunity where the stopped thread proceeds with executing the original system call without being subjected to the newly installed restrictions. The operational impact is severe because an attacker can exploit this gap to execute prohibited operations, such as execve(), which would otherwise be blocked by the seccomp filter. Furthermore, since ptrace allows the tracer to modify registers and arguments during a stop, an adversary could potentially alter the system call number itself before resuming execution, further complicating detection and increasing the potential for privilege escalation or sandbox escape if combined with other vulnerabilities. The silent bypass of security policies undermines the fundamental guarantees provided by seccomp, which is often used in containerized environments to restrict kernel attack surfaces.
From a classification perspective, this vulnerability aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, as it involves a race condition between thread state updates and flag evaluation. It also relates to CWE-841, Improper Enforcement of Behavioral Workflow, because the security control is bypassed due to incorrect sequencing of checks relative to policy application. In terms of MITRE ATT&CK mapping, this behavior facilitates Defense Evasion techniques by allowing an attacker to circumvent application-level restrictions and potentially move laterally or escalate privileges within a compromised environment without triggering immediate alerts associated with standard seccomp violations.
The resolution involves modifying the syscall_trace_enter() logic to re-read the syscall_work flags after ptrace handling is completed but before the final security checks are executed. By refreshing this data, the kernel ensures that any SYSCALL_WORK_SECCOMP flag set by another thread via TSYNC during a ptrace stop is correctly observed and enforced. This fix restores the integrity of the synchronization mechanism between threads and guarantees that seccomp filters apply consistently regardless of timing variations caused by tracing activities. System administrators should ensure their kernels are updated to include this patch, particularly in environments where untrusted code may be traced or where strict container isolation relies on accurate enforcement of system call restrictions.