On Thu, Feb 10, 2022 at 05:18:39PM +0100, Jann Horn wrote:
On Thu, Feb 10, 2022 at 3:53 AM Kees Cook keescook@chromium.org wrote:
Fatal SIGSYS signals were not being delivered to pid namespace init processes. Make sure the SIGNAL_UNKILLABLE doesn't get set for these cases.
Reported-by: Robert Święcki robert@swiecki.net Suggested-by: "Eric W. Biederman" ebiederm@xmission.com Fixes: 00b06da29cf9 ("signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook keescook@chromium.org
kernel/signal.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c index 38602738866e..33e3ee4f3383 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -1342,9 +1342,10 @@ force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t, } /* * Don't clear SIGNAL_UNKILLABLE for traced tasks, users won't expect
* debugging to leave init killable.
* debugging to leave init killable, unless it is intended to exit. */
if (action->sa.sa_handler == SIG_DFL && !t->ptrace)
if (action->sa.sa_handler == SIG_DFL &&(!t->ptrace || (handler == HANDLER_EXIT))) t->signal->flags &= ~SIGNAL_UNKILLABLE;You're changing the subclause:
!t->ptrace
to:
(!t->ptrace || (handler == HANDLER_EXIT))
which means that the change only affects cases where the process has a ptracer, right? That's not the scenario the commit message is talking about...
Sorry, yes, I was not as accurate as I should have been in the commit log. I have changed it to:
Fatal SIGSYS signals (i.e. seccomp RET_KILL_* syscall filter actions) were not being delivered to ptraced pid namespace init processes. Make sure the SIGNAL_UNKILLABLE doesn't get set for these cases.
ret = send_signal(sig, info, t, PIDTYPE_PID); spin_unlock_irqrestore(&t->sighand->siglock, flags);-- 2.30.2