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

Kusaram Devineni
2026-04-03T15:26:22Z

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