[Bug libc/4737] fork is not async-signal-safe

["tom dot honermann at oracle dot com" <sourceware-bugzilla@sourceware.org>]

------- Additional Comments From tom dot honermann at oracle dot com  2008-11-11 21:34 -------
(In reply to comment #6)
Thank you for your comments Nicholas.  

> The purpose of aborting on detection of heap corruption is to prevent deliberate
> heap corruption attacks. As such, allowing further use of the allocator after
> detection of corruption has the potential to open up security holes that the
> fail fast behavior designed to prevent.

I agree that aborting the process when heap corruption is detected is a very
good thing.  I also agree with preventing further use of the allocator after
heap corruption has been detected.  However, those issues are different concerns
than what has been reported in this bug report.

> 
> Furthermore, being async-signal-safe requires that fork be callable from any
> signal handler at any time, which means that in addition to being able to fork
> from a SIGABRT resulting from heap corruption, we must also be able to fork from
> e.g. a SIGALRM handler that can interrupt the allocator at any time.

POSIX requires fork to be callable from any signal handler at any time - which
includes the contexts which you described.  Note that it would be a violation of
POSIX for the signal handler (either before or after calling fork) to call heap
routines.  None of the heap routines (malloc, free, etc...) are required to be
async-signal-safe.  All functions called by a signal handler must be
async-signal-safe - which means that any attack of the heap through manipulation
of a signal handler that calls heap routines would already constitute a defect
in the signal handler (ie, that it called heap routines at all).  The security
issue in that case would be the defect in the signal handler, not that fork was
async-signal-safe.

> 
> As such, making the mutexes recursive would allow
> malloc-from-fork-from-signal-handler to potentially see inconsistent allocator
> state and lead to heap corruption or other errors.

This is true - but would constitute a POSIX violation since heap routines are
not async-signal-safe.

> 
> fork probably needs to stop allocating memory at all.

fork doesn't allocate memory - it isn't permitted to (at least, not via the
heap) due to the async-signal-safe requirement.

The problem reported here is that calls to fork will hang indefinitely if fork
is called from a signal handler while the executing thread holds one of the heap
mutexes.  This hang happens even if the signal handler never calls a heap
routine.  The fact that fork locks all heap related mutexes is a very important
feature for when fork is called from outside of a signal handler (since in that
case, the forked child may go on to use the heap).  However, it breaks fork from
a signal handler by attempting to acquire mutexes that are not needed for the
parent/child processes running in the context of the signal handler.

-- 


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.