From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1500 invoked by alias); 7 Mar 2012 17:53:24 -0000 Received: (qmail 1492 invoked by uid 22791); 7 Mar 2012 17:53:22 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 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, 07 Mar 2012 17:53:11 +0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sources.redhat.com Subject: [Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access Date: Wed, 07 Mar 2012 17:53:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Keywords: glibc_2.15 X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: carlos at systemhalted dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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-03/txt/msg00093.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13690 --- Comment #18 from Rich Felker 2012-03-07 17:52:03 UTC --- You misunderstand the race. Suppose thread A is unlocking the mutex and gets descheduled after the atomic_exchange_rel but before the lll_futex_wake, and thread B is waiting to lock the mutex. At this point, as far thread B can observe, A is no longer a user of the mutex. Thread B obtains the mutex, performs some operations, unlocks the mutex, and assuming (correctly) that it's now the last user of the mutex, destroys it and frees the memory it occupied. Now at some later point, thread A gets scheduled again and crashes accessing freed memory. If you're wondering how thread B could wake up without thread A calling lll_futex_wake, here are several reasons: 1. Never going to sleep due to value mismatch on the original futex wait call. 2. Receipt of a signal, and value mismatch when the signal handler returns and futex wait is called again. 3. Spurious wakes that look like successful returns from wait. These do exist in Linux, and I have not been able to determine the reason, but I have a test program which can successfully produce them in one case (unrelated to mutexes). -- 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.