From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 8A0CC3EF65E for ; Tue, 14 Apr 2026 17:27:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776187629; cv=none; b=T+8MRFk+W4nxaGJ5fNFuy/OOkFrplwkj7Oamf5Uk2W+ji0WpjwsfHWhGhTWNzAMkjkxMVDE1hUcDfarDanJE6INJpTT2NRzorAh8IjBDIU670Jfat6lrqzdIEKfrv/5hWyELWV0xBHo3i3viMW1VUloovlfJWb7exOHjqoNner4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776187629; c=relaxed/simple; bh=Z5TKxlmLOFK097WNb6V54ZUh0ZhldgOZc/ehIng/5j0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TWQO4uWMBkPEZYI2v7UOa3m/l7Y/TJqsLJF+Oi/jxee/sobLCf1EhtpFDdkyGp9Yy0FpcDAnMd0t8KrQb1YPyiy/poSqO3s6PDviJLjL0nNCeIdyWM9iYvYh6u148TAvAlHLNEYUnohYdV/h4h4VuVC6nnp2upTd+ctfluHD7FM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FS3InbiQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FS3InbiQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37096C19425; Tue, 14 Apr 2026 17:27:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776187628; bh=Z5TKxlmLOFK097WNb6V54ZUh0ZhldgOZc/ehIng/5j0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FS3InbiQSsV2QZ4qWaxP2VOC88NMxdpGgJ/EW3RwMtHtqsYbupUbmXFz1OV2DR2Hz iLFR2ospwuQe0sqL2H4hXDTgaVw6JO1Sz5S9JA3mr+GJGgajn182rq+wDqQEvOMShq QHXICpLs7EbmaRgYxOWPTR98C0j4PcbPqOexbd8mZLUb6V/H3Qz8p5kKyBV5ibmIOG pHf7A1nbBDSY+LC4wtkXtw2BaFjZGLHReGpAk2Sh6+bi/VnYkbPtyHxiAC5SvRrWNE j4rqMRylTjpVupJN9TbHrfywWSFs4HDzO42j5APHPfYwQAxLQaz1N/qyNmDlKQfOBl hfzEGTnUVjRHg== Date: Tue, 14 Apr 2026 10:27:07 -0700 From: Kees Cook To: Oleg Nesterov Cc: Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Will Drewry , Kusaram Devineni , Max Ver , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 2/2] seccomp: defer syscall_rollback() to get_signal() Message-ID: <202604141026.4BEA64A4@keescook> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Apr 14, 2026 at 06:48:20PM +0200, Oleg Nesterov wrote: > Currently, seccomp_nack_syscall() calls syscall_rollback() immediately. > Because this restores the original registers, the syscall exit path sees > the original syscall number as the return value. > > This confuses audit_syscall_exit(), trace_syscall_exit(), and ptrace. > > Change seccomp_nack_syscall() to call syscall_set_return_value(-EINTR), > and add the new check_force_sig_seccomp() helper called by get_signal() > which does syscall_rollback() if the signal was sent by seccomp. > > Note that the si_code == SYS_SECCOMP check in check_force_sig_seccomp() > is not 100% reliable, see the comment in check_force_sig_seccomp(), but > I hope we don't really care. > > Reported-by: Max Ver > Closes: https://lore.kernel.org/all/CABjJbFJO+p3jA1r0gjUZrCepQb1Fab3kqxYhc_PSfoqo21ypeQ@mail.gmail.com/ > Signed-off-by: Oleg Nesterov Can we also add a new selftest for this case? I'd like to be sure we don't regress when we make changes in the future... -Kees -- Kees Cook