linux-hardening - Re: [REGRESSION] 5.16rc1: SA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wgkOGmkTu18hJQaJ4mk8hGZc16=gzGMgGGOd=uwpXsdyw@mail.gmail.com>
Date:   Wed, 17 Nov 2021 15:24:24 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Kyle Huey <me@...ehuey.com>,
        Andrea Righi <andrea.righi@...onical.com>,
        Shuah Khan <shuah@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Andy Lutomirski <luto@...capital.net>,
        Will Drewry <wad@...omium.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        linux-hardening@...r.kernel.org,
        "Robert O'Callahan" <rocallahan@...il.com>
Subject: Re: [REGRESSION] 5.16rc1: SA_IMMUTABLE breaks debuggers

On Wed, Nov 17, 2021 at 1:54 PM Kees Cook <keescook@...omium.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?

               Linus