[Bug libc/14750] New: Race condition in posix_spawn vfork usage vs signal handlers

[Bug libc/14750] New: Race condition in posix_spawn vfork usage vs signal handlers

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=14750

             Bug #: 14750
           Summary: Race condition in posix_spawn vfork usage vs signal
                    handlers
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: unassigned@sourceware.org
        ReportedBy: bugdal@aerifal.cx
                CC: drepper.fsp@gmail.com
    Classification: Unclassified


When posix_spawn uses vfork, it does not block signals. This allows the parent
process's signal handlers to get invoked in the child process, corrupting the
parent process's state. For example:

1. Memory state will be as if the signal handler ran, but other state such as
signal dispositions, open files, etc. modified from the signal handler will not
be reflected in the parent.
2. The same signal (assuming the signal was sent to an entire process-group,
which is the main way a signal could arrive in the new child) may be processed
twice in the context of the parent process's memory space.
3. Properties of the child process (e.g. its pid) may end up stored in the
parent process's address space.

These are just a few examples; there should be plenty more ways things can go
wrong.

To fix the problem, the vfork/exec process needs to follow the steps below:

1. Mask all signals (including NPTL-internal ones)
2. vfork
3. In child, reset all signal dispositions to SIG_DFL unless the existing
disposition is SIG_IGN.
4. In child, restore the original signal mask.
5. In child, finish up and exec/_exit.
6. In parent, restore the original signal mask.

Note that step 3 would happen in kernelspace as part of exec anyway, but it
must be done explicitly in userspace to make it safe to unmask signals.

As an alternative, restoring the signal mask, and all of the post-fork work of
posix_spawn, could be outsourced to an external program, i.e. first exec
$prefix/libexec/posix_spawn, which would restore signals, perform the file
actions, etc.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/14750] Race condition in posix_spawn vfork usage vs signal handlers

[sionescu+BugTrackers at cddr dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14750

Stelian Ionescu <sionescu+BugTrackers at cddr dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sionescu+BugTrackers at cddr dot o
                   |                            |rg

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/14750] Race condition in posix_spawn vfork usage vs signal handlers

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=14750

--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> ---
Ping.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/14750] Race condition in posix_spawn vfork usage vs signal handlers

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14750

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/14750] Race condition in posix_spawn vfork usage vs signal handlers

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14750

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #2 from Carlos O'Donell <carlos at redhat dot com> ---
I agree this should be fixed, but I don't see why step (3) or (4) is required.
It seems like a QoI issue. That is to say you want to allow signals targetted
at the child to reach the child, but is it really required?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/14750] Race condition in posix_spawn vfork usage vs signal handlers

[meave390 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14750

jack <meave390 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |meave390 at gmail dot com

--- Comment #5 from jack <meave390 at gmail dot com> ---
Love to visit here this nice blog you need to follow the online latest web site
and connect https://www.facebook.com/freevbucksgen here the free v bucks
generator game online here

-- 
You are receiving this mail because:
You are on the CC list for the bug.