This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/4737] fork is not async-signal-safe
- From: "rsa at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 18 Nov 2008 23:44:08 -0000
- Subject: [Bug libc/4737] fork is not async-signal-safe
- References: <20070704013541.4737.nmiell@comcast.net>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From rsa at us dot ibm dot com 2008-11-18 23:44 -------
A hole was introduced in the concept of fork being async signal safe with the
introduction of at_fork handlers.
The following IEEE interpretation should be very enlightening:
http://standards.ieee.org/reading/ieee/interp/1003-1c-95_int/pasc-1003.1c-37.html
Per the ieee interpretation:
"The implementation must also be required to protect itself
across a fork, for this to occur. But it should NOT be required to
protect itself against a fork from a signal handler, because this
may be impossible to accomplish."
Support for at_fork handlers introduces an window of vulnerability.
"The rationale is very specific that the
handlers should be designed so they **can't** be used when fork is
called in a signal handler which under normal programming practices
meant that they should 'acquire' the mutexes, but the standard does not
require that mutex operations be async safe. This is being referred to
the sponsor for consideration."
There doesn't seem to have been a follow up to the recommendation.
The following discussion held on libc-hacker is pertinent to the implementation
in GLIBC.
http://www.sourceware.org/ml/libc-hacker/2007-02/msg00009.html
The problem is the lock that may be held by both the at_fork handlers and malloc.
I'm not sure if there is _any_ usage of recursive locks in GLIBC.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=4737
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.