From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11536 invoked by alias); 6 Nov 2008 23:10:09 -0000 Received: (qmail 27684 invoked by uid 48); 6 Nov 2008 23:08:54 -0000 Date: Thu, 06 Nov 2008 23:10:00 -0000 Message-ID: <20081106230854.27682.qmail@sourceware.org> From: "nmiell at comcast dot net" 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/msg00024.txt.bz2 ------- Additional Comments From nmiell at comcast dot net 2008-11-06 23:08 ------- 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. 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. 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. fork probably needs to stop allocating memory at all. -- 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.