This is the mail archive of the
mailing list for the glibc project.
[Bug nptl/19951] Use after free in pthread_detach
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 17 Jan 2017 07:08:45 +0000
- Subject: [Bug nptl/19951] Use after free in pthread_detach
- Auto-submitted: auto-generated
- References: <firstname.lastname@example.org/bugzilla/>
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
CC| |carlos at redhat dot com
--- 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))
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;
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.
(a) Check if I'm detached.
(b) If detached then free resources.
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.