From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7876 invoked by alias); 23 May 2012 19:50:42 -0000 Received: (qmail 7808 invoked by uid 22791); 23 May 2012 19:50:40 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_GJ X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 May 2012 19:50:26 +0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sources.redhat.com Subject: [Bug nptl/14147] New: Async cancellation left active after longjmp out of signal handler Date: Wed, 23 May 2012 19:50:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2012-05/txt/msg00301.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=14147 Bug #: 14147 Summary: Async cancellation left active after longjmp out of signal handler Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: nptl AssignedTo: unassigned@sourceware.org ReportedBy: bugdal@aerifal.cx CC: drepper.fsp@gmail.com Classification: Unclassified If a signal handler interrupts a function which is async-signal-safe, it's valid to exit the signal handler with longjmp. Suppose the interrupted function is also a cancellation point. Due to NPTL's implementation of cancellation points (switch to async cancellation mode, invoke the syscall, switch back), the cancellation mode will get left as asynchronous, contrary to the expectations of a conforming application, and subsequent code that is not async-cancellation-safe will get run with async cancellation, possibly causing severe memory corruption when a cancellation request arrives. This bug is related to bug #12683 (also reported by me), but I'm reporting it separately because it's not a rare race condition but breakage in a specific usage case that will occur without any race. Fixing all of these issues requires abandoning the naive approach of wrapping syscalls in switches to/from async cancellation mode, and instead having the cancellation signal handler check (via program counter comparison, either directly or using whatever fancy DWARF stuff is popular) to determine whether the interrupted thread was blocked at a cancellation point, and thus whether to act on cancellation. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.