Bug 19430 - __reclaim_stacks is bogus
Summary: __reclaim_stacks is bogus
Alias: None
Product: glibc
Classification: Unclassified
Component: nptl (show other bugs)
Version: 2.23
: P2 normal
Target Milestone: ---
Assignee: Florian Weimer
Depends on:
Reported: 2016-01-05 16:35 UTC by Florian Weimer
Modified: 2020-07-03 11:35 UTC (History)
4 users (show)

See Also:
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
Description Florian Weimer 2016-01-05 16:35:12 UTC
If I read the __reclaim_stacks code correctly, it frees the stack of all other threads after a fork.  This is not a safe thing to do because pointers to on-stack data may have been written to global variables or shared with the current thread by other means, and those objects have to be remain valid after fork.
Comment 1 Torvald Riegel 2017-01-12 11:14:47 UTC
I don't think it is required to preserve objects on the stack of threads that have not been re-created in the child after fork().  POSIX states that only one thread will exist in the forked child.  This seems equivalent to saying that all threads are duplicated in the child, but all child but the one that is the duplicate of the parent thread that called fork() are terminated before that remaining child thread continues execution.  Given that objects on stacks of terminated threads are not required to be preserved either, I think this is not a bug. Please close this bug if you agree with this reasoning.
Comment 2 Florian Weimer 2017-01-12 12:01:08 UTC
POSIX says:

“If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space”

This suggests to me that other thread stacks and TLS variables need to be preserved because they are part of the address space as well (at least if the addresses of these objects have been taken and published in some way to the current thread).
Comment 3 Torvald Riegel 2017-01-12 15:53:14 UTC
I think we need a clarification by the Austin Group.
Comment 4 Florian Weimer 2017-01-12 16:05:48 UTC
Filed as: http://austingroupbugs.net/view.php?id=1114
Comment 5 Florian Weimer 2019-10-30 10:57:47 UTC
POSIX thinks this is acceptable.

We will have to see how this interacts with libraries that put references to thread-local data into global data structures. I suppose those would have to use an indirection, storing the shared data on the heap, and only a pointer to that in TLS.
Comment 6 Florian Weimer 2020-07-03 11:35:12 UTC
C11 says this:

The result of attempting to indirectly access an object with thread storage duration from a thread other than the one with which the object is associated is implementation-defined.

So we can say that accessing TLS data after fork is undefined.