[Bug nptl/19951] Use after free in pthread_detach

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com
            Version|2.19                        |2.25

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
I can confirm this issue.

Fundamentally this code in pthread_detach is flawed:

 36   /* Mark the thread as detached.  */
 37   if (atomic_compare_and_exchange_bool_acq (&pd->joinid, pd, NULL))
 38     {
 39       /* There are two possibilities here.  First, the thread might
 40          already be detached.  In this case we return EINVAL.
 41          Otherwise there might already be a waiter.  The standard does
 42          not mention what happens in this case.  */
 43       if (IS_DETACHED (pd))
 44         result = EINVAL;
 45     }
 46   else
 47     /* Check whether the thread terminated meanwhile.  In this case we
 48        will just free the TCB.  */
 49     if ((pd->cancelhandling & EXITING_BITMASK) != 0)
 50       /* Note that the code in __free_tcb makes sure each thread
 51          control block is freed only once.  */
 52       __free_tcb (pd);

Once ownership of PD is released on line 37 we may never be touched again.

There is a resource leak that we can't prevent in the current implementation.

e.g.

T1:
(a) Check if I'm detached.
(b) If detached then free resources.
(c) Exit.

Any thread T2 may make T1 detached after (a) and create a scenario where T2
doesn't know if T1 was detached before (a) or after (a) and can't check without
risk of segfault if PD is unmapped.

The detach sequence needs to be rewritten such that (a) is done atomically and
is not just a check but writes information back into PD to indicate to T2 that
it has already shut down far enough that it will not be freeing it's own
resources. In that case T2 can, in pthread_detach, carry out the free of the
resources, knowing PD is still around.

The only immediate workaround I can suggest is to start the thread detached
rather than trying to set the detached status at a later point in time.

I do not expect this to get fixed in 2.25 (Feb 1st 2017).

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