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.
https://git.kernel.org/stable/c/eca5ed4200f0be3e91f8a237b1f37582030a93a8
https://git.kernel.org/stable/c/ab4647459098a43e9d6fdb860836f08c962f3774
https://git.kernel.org/stable/c/8709e7e1dd7d7de0651e61700edf24f5784f9243
https://git.kernel.org/stable/c/4a3591287fb7f808e209b4974ed337f609a2006b
https://git.kernel.org/stable/c/459f33f82864723a7fa366cf1091d9c6c893b6b2
https://git.kernel.org/stable/c/23001ee5d8631e30192cde6f6d3ccb6805570499
https://git.kernel.org/stable/c/22bb836fc133331982c264227a899d4b26a09706
https://git.kernel.org/stable/c/09e8880ce5409bdb84da991b053d7087502c181e