Re: [REGRESSION] 5.16rc1: SA_IMMUTABLE breaks debuggers

[Kees Cook <keescook@chromium.org>]

On Wed, Nov 17, 2021 at 03:24:24PM -0800, Linus Torvalds wrote:
> On Wed, Nov 17, 2021 at 1:54 PM Kees Cook <keescook@chromium.org> wrote:
> >
> > The SA_IMMUTABLE change was to deal with failures seen in the seccomp
> > test suite after the recent fatal signal refactoring. Mainly that a
> > process that should have effectively performed do_exit() was suddenly
> > visible to the tracer.
> 
> I think this basically shows that the conversion from do_exit() to
> fatal_signal() was just wrong. The "do_exit()" wasn't really a signal,
> and can't be treated as such.
> 
> That said, instead of reverting, maybe we can just mark the cases
> where it really is about sending a synchronous signal, vs sending an
> explicitly fatal signal.
> 
> It's basically the "true" condition to force_sig_info_to_task(), so
> the fix might be just
> 
>   @@ -1323,7 +1323,8 @@ force_sig_info_to_task(struct kernel_siginfo
> *info, struct task_struct *t, bool
>         blocked = sigismember(&t->blocked, sig);
>         if (blocked || ignored || sigdfl) {
>                 action->sa.sa_handler = SIG_DFL;
>   -             action->sa.sa_flags |= SA_IMMUTABLE;
>   +             if (sigdfl)
>   +                     action->sa.sa_flags |= SA_IMMUTABLE;
>                 if (blocked) {
>                         sigdelset(&t->blocked, sig);
>                         recalc_sigpending_and_wake(t);
> 
> Kyle, does that fix your test-case? And Kees - yours?

Yup, the correct behavior is retained for me with this change.

(nit: should the "sigdfl" argument be renamed "immutable" for clarity
in this function?)

-- 
Kees Cook