From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout03.his.huawei.com (canpmsgout03.his.huawei.com [113.46.200.218]) (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 2082830C62D for ; Mon, 13 Jul 2026 02:40:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783910425; cv=none; b=Vk1PnJ2A8ExVRBNk/iGqAYsVKPCdqiomWKEnIdmKW3XHTNRLK/iPyxyHgMGZl+XCwJsbfL5krz+SSQMjC+RPuOhLcv7hf2XMlq7VEhkgTa0EqLXlbCUUe8NBaRPbEKrl40tffd0GxUHgOu30VyYOFRRdElcZX3mIMU55EaWDjPE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783910425; c=relaxed/simple; bh=V4qFTV6doNdJbZ7x7k4UGaH9pNIYoEcIm9RjnTfuTGo=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=BHGn3xM7KX9+VEQxgckdi08wYpdk1uJkgx26be0q408Eq27SD4nvziTXVhDmIB0iPz2SIXJvv2JWXGQpKhAVJpOS74wsQ12PMfD/d5dQAI1YK3OftPRw6TWrIcBOZg+ABfG2YhGeUk85p2tJTlba1XJL8cJAQQiM0y5omm+EL9Y= 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=0iaYbBUI; arc=none smtp.client-ip=113.46.200.218 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="0iaYbBUI" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=8QbOtz4UbcKUN1j0SdsWTF2N8dLC2m67SZ5PcoRJdHE=; b=0iaYbBUI+4Ghdio/BuiO2W84VlzvLaePMz2NBBVU3z0eFo69fEwEt9D2AS9Q9jsHP8VXiQJ9f 11VuGDaEv0XdK4TrMYmD5SPoTpBlUcTKYXcQuJIJFTp7S1rWgF/UtNF3OQl9UCG+kKx7q5vPJZr rev6UdUfTqZtHVhL+3IoRXo= Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4gz5zH72TzzpSv5; Mon, 13 Jul 2026 10:31:23 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 890494058C; Mon, 13 Jul 2026 10:40:12 +0800 (CST) Received: from [10.67.109.254] (10.67.109.254) 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:40:11 +0800 Message-ID: <42d49756-2b04-4c0b-ac9b-c42d902f486a@huawei.com> Date: Mon, 13 Jul 2026 10:40:10 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RESEND] entry: Fix seccomp bypass after ptrace with TSYNC To: Thomas Gleixner , , , , , References: <20260709073030.3844316-1-ruanjinjie@huawei.com> <874ii4r03u.ffs@fw13> From: Jinjie Ruan In-Reply-To: <874ii4r03u.ffs@fw13> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To dggpemf500011.china.huawei.com (7.185.36.131) On 7/12/2026 6:08 PM, Thomas Gleixner wrote: > On Thu, Jul 09 2026 at 15:30, Jinjie Ruan wrote: >> Sashiko review pointed out the following issue[1]. >> >> 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 replacing the cached seccomp check with a call to >> seccomp_permit_syscall(), which re-reads the thread's up-to-date >> TIF_SECCOMP flag and thus correctly observes the flag if it was set >> during the ptrace stop. > > No, we are not doing this unconditionally. > > Thanks, > > tglx > --- > --- a/include/linux/entry-common.h > +++ b/include/linux/entry-common.h > @@ -98,6 +98,8 @@ static __always_inline long syscall_trac > ret = arch_ptrace_report_syscall_entry(regs); > if (ret || (work & SYSCALL_WORK_SYSCALL_EMU)) > return -1L; > + /* ptrace might have changed work flags */ > + work = READ_ONCE(current_thread_info()->syscall_work); This avoids the performance penalty of a full seccomp check on every syscall while still fixing the race. Will update it in v2. Thanks. > } > > /* Do seccomp after ptrace, to catch any tracer changes. */ > >