linux-hardening - Re: [PATCH 0/3] signal: HANDLER_EXIT should clear SIGNAL

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 for Android: free password hash cracker in your pocket

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

Message-ID: <202202101827.4B16DF54@keescook>
Date:   Thu, 10 Feb 2022 18:53:42 -0800
From:   Kees Cook <keescook@...omium.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Robert Święcki <robert@...ecki.net>,
        Andy Lutomirski <luto@...capital.net>,
        Will Drewry <wad@...omium.org>, linux-kernel@...r.kernel.org,
        linux-hardening@...r.kernel.org
Subject: Re: [PATCH 0/3] signal: HANDLER_EXIT should clear SIGNAL_UNKILLABLE

On Thu, Feb 10, 2022 at 07:47:00PM -0600, Eric W. Biederman wrote:
> Kees Cook <keescook@...omium.org> writes:
> > The common accessors for the bits are set_syscall_work()/clear_syscall_work()
> > but I don't see anything to operate on an entire mask. Maybe it needs to
> > grow something like reset_syscall_work()?
> 
> Oh.  I hadn't realized SYSCALL_WORK_EXIT and TIF_SYSCALL_WORK were
> masks.  Yes it looks like a simple addition of reset_syscall_work()
> and calling it from force_sig_info when HANDLER_EXIT will hide these
> events.

Yeah, it's varied by features, architectures, etc. The good news is it's
WAY nicer now after the USER_DISPATCH. :)

> When you say the events are corrupted did you mean they return wrong data
> to userspace or simply that the events should not fire?

It's mainly about the exit stuff having never been run before on these
kinds of process states, so things don't make sense. For example, on the
SIGSYS death, the registers have been rewound for the coredump, so when
the exit trace runs on x86 it sees the syscall return value as equal to
the syscall number (since %rax is used for the syscall number on entry
and for the syscall result on exit). So when a tracer watches a seccomp
fatal SIGSYS, it sees the syscall exit before it sees the child exit
(and therefore the signal). For example, x86_64 write (syscall number
1), will return as if it had written 1 byte. :P

So, it's not harmful, but it's confusing and weird. :)

> I am trying to figure out if there is a case to be made that it was a
> bug that these events were missing.

I don't think so -- the syscall did not finish, so there isn't a valid
return code. The process exited before it completed.

-- 
Kees Cook