From: Oleg Nesterov <oleg@redhat.com>
To: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: tglx@kernel.org, peterz@infradead.org, luto@kernel.org,
kees@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] entry: Fix seccomp bypass after ptrace with TSYNC
Date: Wed, 14 Oct 2026 11:21:46 +0200 [thread overview]
Message-ID: <as9Jqi5BvSZWfxj8@redhat.com> (raw)
In-Reply-To: <20260713025712.416366-1-ruanjinjie@huawei.com>
On 07/13, Jinjie Ruan wrote:
>
> 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.
I agree with this patch, but SECCOMP_FILTER_FLAG_TSYNC can also happen
after syscall_trace_enter() re-reads ->syscall_work ?
And this race is possible even without ptrace, SECCOMP_FILTER_FLAG_TSYNC
from another thread can happen after syscall_enter_from_user_mode_work()
reads ->syscall_work ?
I think we don't really care, but I don't understand the security concerns.
If debugger controls the process before it installs the seccomp filters, it
can simply nack sys_seccomp().
In short, does CVE-2026-89603 make real sense?
Oleg.
> --- a/include/linux/entry-common.h
> +++ b/include/linux/entry-common.h
> @@ -97,6 +97,9 @@ static __always_inline long syscall_trace_enter(struct pt_regs *regs, unsigned l
> if (!arch_ptrace_report_syscall_permit_entry(regs) ||
> (work & SYSCALL_WORK_SYSCALL_EMU))
> return -1L;
> +
> + /* ptrace might have changed work flags */
> + work = READ_ONCE(current_thread_info()->syscall_work);
> }
>
> /* Do seccomp after ptrace, to catch any tracer changes. */
> --
> 2.34.1
>
next prev parent reply other threads:[~2026-10-14 9:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 2:57 [PATCH v2] entry: Fix seccomp bypass after ptrace with TSYNC Jinjie Ruan
2026-07-14 7:36 ` Jinjie Ruan
2026-07-14 14:40 ` [tip: core/entry] " tip-bot2 for Jinjie Ruan
2026-10-14 9:21 ` Oleg Nesterov [this message]
2026-10-15 16:16 ` [PATCH v2] " Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=as9Jqi5BvSZWfxj8@redhat.com \
--to=oleg@redhat.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=ruanjinjie@huawei.com \
--cc=tglx@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.