linux-kernel - Re: [Bug 200447] infinite loop in fork syscall

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] [day] [month] [year] [list]

Date:   Wed, 11 Jul 2018 14:08:15 +0200
From:   Oleg Nesterov <oleg@...hat.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [Bug 200447] infinite loop in fork syscall

On 07/10, Eric W. Biederman wrote:
>
> > 2. To simplify, lets suppose we add the new PF_INFORK flag. Yes, this is bad,
> >    we can do better. I think we can simply add "struct hlist_head forking_threads"
> >    into signal_struct, so complete_signal() can just do hlist_for_each_entry()
> >    rather than for_each_thread() + PF_INFORK check. We don't even need a new
> >    member in task_struct.
>
> We still need the distinction between multi-process signals and single
> process signals (which is the hard part).  For good performance of
> signal delivery to multi-threaded tasks we still need a new member in
> signal_struct.  Plus it is a bit more work to update the list or even
> walk the list than a sequence counter.
>
> So I think adding a sequence counter to let us know about multiprocess
> signals is the local optimum.

But we can not rely on on a sequence counter, there are other reasons why
fork() should fail even if fatal_signal_pending() == F and the counter was
not changed (no multi-process signals).

> > 3. copy_process() can simply block/unblock all signals (except KILL/STOP), see
> >    the "patch" below.
>
> All signals are effectively blocked for the duration of the fork for the
> calling task.    Where we get into trouble and where we need a fix for
> correctness is that another thread can dequeue the signal.   Blocking
> signals of the forking task does not change that.

See my reply to Linus. Please look at the change in complete_signal().

> I think that reveals another bug in our current logic.  For blocked
> multi-process signals we don't ensure they get delivered to both the
> parent and the child if the signal logically comes in after the fork.

I thougth thought this too. I simply do not know if this is right or not.

For now I assume that this is correct and by design, iow if fork() is called
with (say) SIGTERM blocked, then we do not care if kill_pgrp(SIGTERM) misses
the new child.

If we want to change this, I think this needs another discussion.

Oleg.