From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18434 invoked by alias); 11 Nov 2008 21:35:48 -0000 Received: (qmail 6817 invoked by uid 48); 11 Nov 2008 21:34:33 -0000 Date: Tue, 11 Nov 2008 21:35:00 -0000 Message-ID: <20081111213433.6816.qmail@sourceware.org> From: "tom dot honermann at oracle dot com" To: glibc-bugs@sources.redhat.com In-Reply-To: <20070704013541.4737.nmiell@comcast.net> References: <20070704013541.4737.nmiell@comcast.net> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/4737] fork is not async-signal-safe X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00037.txt.bz2 ------- 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.