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

[Kusaram Devineni]

On 23-03-2026 17:39, Oleg Nesterov wrote:
> Perhaps _something_ like the change below makes more sense?

We have been working internally on a related issue in the same 
seccomp/signal area, so sharing our thoughts here in case they are useful.

This change does seem closer to the real condition than checking
SECCOMP_MODE_DEAD in syscall_exit_work(). In our analysis too, the bogus 
syscall-exit report appears to be a real issue, in seccomp paths which 
do syscall_rollback(), e.g. the fatal kill path and also 
SECCOMP_RET_TRAP, the return register no longer reflects a valid exit 
result. So ptrace can observe a value that did not come from a completed 
syscall.

Because of that, using SECCOMP_MODE_DEAD still feels a bit broader than 
the exact condition. It couples syscall-exit suppression to a persistent 
seccomp task state, while the reason to suppress reporting seems more 
specific to a single syscall instance: once that syscall has been rolled 
back, it never actually completed, so there is no valid exit result to 
report. From that point of view, a per-syscall “aborted after rollback” 
condition still feels like the more natural abstraction.

It also seems worth considering whether the same issue extends beyond 
ptrace syscall-exit reporting to other exit-side observers such as 
audit_syscall_exit() and trace_syscall_exit().

Also, on the TODO from the RFC:

> 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.

while tracing the same overall issue locally, we hit another path where 
the forced fatal SIGSYS could be taken off the normal delivery path 
before get_signal() handled it, in our case via signalfd. There,
force_sig_seccomp(..., true) marks SIGSYS as SA_IMMUTABLE via 
HANDLER_EXIT, but signalfd could still dequeue it before normal fatal 
delivery.

So this direction looks better than the original RFC, but for the 
overall solution to be reliable, it would probably also need to ensure 
that a forced fatal SA_IMMUTABLE signal is not bypassed by other 
signal-ordering, delivery, or consumption paths.

Thanks
Kusaram