CVE-2026-89603
massSeccomp Filter Bypass via ptrace/TSYNC Race in Linux Kernel Syscall Entry
A race condition in the Linux kernel's syscall entry path (syscall_trace_enter()) allows a newly installed seccomp filter to be silently bypassed. When a thread is stopped for ptrace, another thread in the same process can attach a seccomp filter with SECCOMP_FILTER_FLAG_TSYNC; the stopped thread gets the SYSCALL_WORK_SECCOMP flag set, but the entry path checks a stale cached copy of the work flags sampled before the ptrace stop, so the filter is never applied to the syscall in flight. An unprivileged local attacker (or a tracer cooperating with the traced process) can exploit this window to execute a syscall the filter was meant to prohibit — notably execve — including syscalls whose number was rewritten by the tracer during the stop. This primarily threatens sandboxing technologies that rely on seccomp for syscall restriction, such as container runtimes, browser and application sandboxes, and systemd's SystemCallFilter. CVSS 3.1 is 8.4 (high; local vector, low privileges, changed scope, high confidentiality/integrity impact); no public proof of concept or in-the-wild exploitation is known.
What to do: Apply kernel updates from your distribution or upstream as soon as a build containing the syscall_trace_enter() fix (re-reading syscall_work flags after ptrace) is released, prioritizing hosts that run seccomp-based sandboxes, containers, or systemd services with SystemCallFilter. Until patched, recognize that local, untrusted code inside sandboxed workloads may be able to execute syscalls the sandbox intends to block, so treat sandbox boundaries on unpatched kernels as weakened. Check whether your kernel vendor has backported the fix and verify with vendor advisories referencing this CVE.
| Linux kernel | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
In the news0 stories
No ingested article mentions this CVE yet.