From nobody Sat Jul 25 22:33:06 2026 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 86E8D320CBE for ; Mon, 13 Jul 2026 02:57:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.187 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783911451; cv=none; b=TRQ01fFJUhMR2eqykpxag+OCo0u0MXRKDwb4akgvozKdfMveFwQijuyGZvpfbLZUK/VmtXpjD9L5G7vcZM/uMtriVWhpDAOJxN5v2YJv5ng7Vf35oW/Q8+SCiMgOetZY4V36eho5bInLssXTAKYIvCGccJFEi3lIRNjr6hM2ZMA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783911451; c=relaxed/simple; bh=Wg8ZkUuj/6HMbetz3B7WvpnSu9NawQGGLgOeIbcIR8A=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=GdCRDb++m3MDzBjMRewo5aei2rGyfCFnoXBWNQlmYiebyA+NrBF/T4ByPBJOSQ2HsO23DG+j0vpscchdN+SCVZd7FbYDGR9mtTcjDz0mArQAzCdMEyXlJJiTtDaP7o2s5S0S93nJQlIcTGcW07ugq3vEhrkQN5dcElDd0kki19Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=3n1XzgNb; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=3n1XzgNb; arc=none smtp.client-ip=45.249.212.187 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="3n1XzgNb"; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="3n1XzgNb" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=Uk4XdeCad1/FyJFg0LLIpfAPdBLnDWi4sOeuantQIRQ=; b=3n1XzgNbkfNceJwpzgrILgql/rEh+nisO6aG9WzX3wAJJ2snFcZdJ96qDpm/XiZixAvMs8GTN 9Dx08IEnd+yUlg3dzeG77RTagoqRLo1tRDoj7dN4okp588KdSyw8cgivVox6YnpaaMov22AqM9x oGEy3y/HaALEFgG57D3SohE= Received: from canpmsgout07.his.huawei.com (unknown [172.19.92.160]) by szxga01-in.huawei.com (SkyGuard) with ESMTPS id 4gz6Y01ZKPz1BFMm for ; Mon, 13 Jul 2026 10:57:08 +0800 (CST) dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=Uk4XdeCad1/FyJFg0LLIpfAPdBLnDWi4sOeuantQIRQ=; b=3n1XzgNbkfNceJwpzgrILgql/rEh+nisO6aG9WzX3wAJJ2snFcZdJ96qDpm/XiZixAvMs8GTN 9Dx08IEnd+yUlg3dzeG77RTagoqRLo1tRDoj7dN4okp588KdSyw8cgivVox6YnpaaMov22AqM9x oGEy3y/HaALEFgG57D3SohE= Received: from mail.maildlp.com (unknown [172.19.162.92]) by canpmsgout07.his.huawei.com (SkyGuard) with ESMTPS id 4gz6LD63MfzLlTK; Mon, 13 Jul 2026 10:47:48 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id CA4F040565; Mon, 13 Jul 2026 10:57:05 +0800 (CST) Received: from huawei.com (10.90.53.73) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 13 Jul 2026 10:57:05 +0800 From: Jinjie Ruan To: , , , , CC: Subject: [PATCH v2] entry: Fix seccomp bypass after ptrace with TSYNC Date: Mon, 13 Jul 2026 10:57:12 +0800 Message-ID: <20260713025712.416366-1-ruanjinjie@huawei.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To dggpemf500011.china.huawei.com (7.185.36.131) Content-Type: text/plain; charset="utf-8" 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. Cc: Kees Cook Cc: Thomas Gleixner Cc: Andy Lutomirski Cc: Will Drewry Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260629132914.1135C1F000E9@smtp.kernel.o= rg/ Fixes: 142781e108b1 ("entry: Provide generic syscall entry functionality") Signed-off-by: Jinjie Ruan --- v2: - Adopt lighter-weight approach suggested by Thomas: re-read syscall_work after ptrace instead of calling seccomp_permit_syscall() unconditionally. - Update the commit message to reflect the actual implementation. --- include/linux/entry-common.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/entry-common.h b/include/linux/entry-common.h index 07d97def7dcb..299f13c78a6f 100644 --- 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 =3D READ_ONCE(current_thread_info()->syscall_work); } =20 /* Do seccomp after ptrace, to catch any tracer changes. */ --=20 2.34.1