Re: [RFC PATCH] ptrace: don't report syscall-exit if the tracee was killed by seccomp

[Oleg Nesterov]

On 03/22, Andrew Morton wrote:
>
> On Sun, 22 Mar 2026 14:44:54 +0100 Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
>
> > __seccomp_filter() does
> >
> > 	case SECCOMP_RET_KILL_THREAD:
> > 	case SECCOMP_RET_KILL_PROCESS:
> > 	...
> > 		/* Show the original registers in the dump. */
> > 		syscall_rollback(current, current_pt_regs());
> >
> > 		/* Trigger a coredump with SIGSYS */
> > 		force_sig_seccomp(this_syscall, data, true);
> >
> > syscall_rollback() does regs->ax == orig_ax. This means that
> > ptrace_get_syscall_info_exit() will see .is_error == 0. To the tracer,
> > it looks as if the aborted syscall actually succeeded and returned its
> > own syscall number.
> >
> > And since force_sig_seccomp() uses force_coredump == true, SIGSYS won't
> > be reported (see the SA_IMMUTABLE check in get_signal()), so the tracee
> > will "silently" exit with error_code == SIGSYS after the bogus report.
> >
> > Change syscall_exit_work() to avoid the bogus single-step/syscall-exit
> > reports if the tracee is SECCOMP_MODE_DEAD.
> >
> > TODO: With or without this change, get_signal() -> ptrace_signal() may
> > report other !SA_IMMUTABLE pending signals before it dequeues SIGSYS.
> > Perhaps it makes sense to change get_signal() to check SECCOMP_MODE_DEAD
> > too and prioritize the fatal SIGSYS.
>
> AI review has questions:
> 	https://sashiko.dev/#/patchset/ab_yVqQ7WW3flal3@xxxxxxxxxx

Excellent question ;) Thanks sashiko!

I will have this in mind when (if) I send V2.

So far my main concern is the behavioral change caused by my RFC, I will wait
for more comments before that.

In any case: yes! I have missed another syscall_rollback() on SECCOMP_RET_TRAP in
__seccomp_filter(). In this case force_sig_seccomp() uses force_coredump == false,
so SIGSYS will be reported. But this doesn't really make a difference wrt ptrace
confusion.

Thanks!

Oleg.