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

[Andrew Morton <akpm@linux-foundation.org>]

On Sun, 22 Mar 2026 14:44:54 +0100 Oleg Nesterov <oleg@redhat.com> 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@redhat.com