Re: [PATCH 13/20] signal: Implement force_fatal_sig

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/20/21 13:05, Linus Torvalds wrote:
On Wed, Oct 20, 2021 at 7:45 AM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:

Add a simple helper force_fatal_sig that causes a signal to be
delivered to a process as if the signal handler was set to SIG_DFL.

Reimplement force_sigsegv based upon this new helper.

Can you just make the old force_sigsegv() go away? The odd special
casing of SIGSEGV was odd to begin with, I think everybody really just
wanted this new "force_fatal_sig()" and allow any signal - not making
SIGSEGV special.


I'm rather nervous about all this, and I'm also nervous about the existing code. A quick skim is finding plenty of code paths that assume force_sigsegv (or a do_exit that this series touches) are genuinely unrecoverable. For example:

- rseq: the *kernel* will be fine if a signal is handled, but the userspace process may be in a very strange state.

- bprm_execve: The comment says it best:

        /*
         * If past the point of no return ensure the code never
         * returns to the userspace process.  Use an existing fatal
         * signal if present otherwise terminate the process with
         * SIGSEGV.
         */
        if (bprm->point_of_no_return && !fatal_signal_pending(current))
                force_sigsegv(SIGSEGV);

- vm86: already discussed

Now force_sigsegv() at least tries to kill the task, but not very well. With the whole series applied and force_sigsegv() gone, these errors become handleable, and that needs real care.

(I don't think bprm_execve() is exploitable. It looks like it's attackable in the window between setting point_of_no_return and unshare_sighand(), but I'm not seeing any useful way to attack it unless a core dump is already in progress or a *different* fatal signal is already pending, and in either of those cases we're fine.)



[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux