Re: [RFC PATCH 2/2] seccomp: defer syscall_rollback() to get_signal()

[Oleg Nesterov]

On 04/14, Kees Cook wrote:
>
> 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 <dudududumaxver@xxxxxxxxx>
> > Closes: https://lore.kernel.org/all/CABjJbFJO+p3jA1r0gjUZrCepQb1Fab3kqxYhc_PSfoqo21ypeQ@xxxxxxxxxxxxxx/
> > Signed-off-by: Oleg Nesterov <oleg@xxxxxxxxxx>
>
> Can we also add a new selftest for this case?

Yes sure. but do you agree with this RFC approach?

See also 0/2. Perhaps SYSCALL_WORK_SYSCALL_XXX makes more sense?

I do think it makes more sense and it is closer to my initial
"[RFC PATCH] ptrace: don't report syscall-exit if the tracee was killed by seccomp"
attempt/

But I'm afraid this change would be "too visible".

> I'd like to be sure we
> don't regress when we make changes in the future...

Yes, I understand.

And just in case... I ran tools/testing/selftests/seccomp/seccomp_bpf, it
doesn't show any regression.

Oleg.