All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Kees Cook <kees@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@kernel.org>, Will Drewry <wad@chromium.org>,
	Max Ver <dudududumaxver@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] ptrace: don't report syscall-exit if the tracee was killed by seccomp
Date: Sun, 22 Mar 2026 16:14:01 +0100	[thread overview]
Message-ID: <acAHOQrovQ9c1lBD@redhat.com> (raw)
In-Reply-To: <6E69C3F0-0691-4115-AE36-F5E5743C942A@kernel.org>

On 03/22, Kees Cook wrote:
>
> On March 22, 2026 6:44:54 AM PDT, 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.
> >
> >Reported-by: Max Ver <dudududumaxver@gmail.com>
> >Closes: https://lore.kernel.org/all/CABjJbFJO+p3jA1r0gjUZrCepQb1Fab3kqxYhc_PSfoqo21ypeQ@mail.gmail.com/
> >Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> >---
> > include/linux/entry-common.h | 3 +++
> > include/linux/seccomp.h      | 8 ++++++++
> > kernel/seccomp.c             | 3 ---
> > 3 files changed, 11 insertions(+), 3 deletions(-)
> >
> >diff --git a/include/linux/entry-common.h b/include/linux/entry-common.h
> >index f83ca0abf2cd..5c62bda9dcf9 100644
> >--- a/include/linux/entry-common.h
> >+++ b/include/linux/entry-common.h
> >@@ -250,6 +250,9 @@ static __always_inline void syscall_exit_work(struct pt_regs *regs, unsigned lon
> > 	if (work & SYSCALL_WORK_SYSCALL_TRACEPOINT)
> > 		trace_syscall_exit(regs, syscall_get_return_value(current, regs));
> >
> >+	if (killed_by_seccomp(current))
> >+		return;
>
> Hmm. I'm still not convinced this is right,

Me too actually ;)

That is why RFC. So:

	- Do you agree that the current behaviour is not really "sane" and
	  can confuse ptracers?

	- If yes, what else do you think we can do? No, I no longer think it
	  makes sense to change the ptrace_get_syscall_info_exit() paths...


> but if we make this change, I'd want to see a behavioral test added
> (likely to the seccomp self tests), and to make sure the rr test suite doesn't regress.

OK. I'll try to take a look at these tests and possibly add another one.

But (sorry) not the next week, I will be travelling.

Oleg.


  reply	other threads:[~2026-03-22 15:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-22 13:44 [RFC PATCH] ptrace: don't report syscall-exit if the tracee was killed by seccomp Oleg Nesterov
2026-03-22 14:47 ` Kees Cook
2026-03-22 15:14   ` Oleg Nesterov [this message]
2026-03-23 12:09     ` Oleg Nesterov
2026-04-03 15:26       ` Kusaram Devineni
2026-04-03 15:48         ` Oleg Nesterov
2026-04-03 17:16           ` Kusaram Devineni
2026-04-04 14:33             ` Oleg Nesterov
2026-04-05 15:57               ` Oleg Nesterov
2026-04-06 10:43                 ` Kusaram Devineni
2026-03-22 16:36 ` Andrew Morton
2026-03-22 17:32   ` Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acAHOQrovQ9c1lBD@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dudududumaxver@gmail.com \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@kernel.org \
    --cc=wad@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.