From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28324 invoked by alias); 7 Mar 2012 10:30:18 -0000 Received: (qmail 28314 invoked by uid 22791); 7 Mar 2012 10:30:17 -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 10:30:06 +0000 From: "drepper.fsp at gmail dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access Date: Wed, 07 Mar 2012 10:30: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: drepper.fsp at gmail dot com 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: Status CC 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/msg00089.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13690 Ulrich Drepper changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |WAITING CC| |drepper.fsp at gmail dot | |com --- Comment #17 from Ulrich Drepper 2012-03-07 10:29:21 UTC --- (In reply to comment #0) > Thus, the lll_unlock() call in pthread_mutex_unlock.c will be expanded as: > int *__futex = &(mutex->__data.__lock); > int __val = atomic_exchange_rel (__futex, 0); > if (__builtin_expect (__val > 1, 0)) /* A */ > lll_futex_wake (__futex, 1, ((mutex)->__data.__kind & 128)); /* B */ > > On point "A", the mutex is actually unlocked, so other threads can > lock the mutex, unlock, destroy and free. If the mutex was destroyed > and freed by other thread, reading '__kind' on point "B" is not valid. You read the code incorrectly. If B is reached there must be another thread using the mutex. It is currently waiting. In that case it is invalid to destroy the mutex. In any case would there be another memory access, from the thread which is woken by the lll_futex_wake call. The same applies to whatever you try to change with your patch. Again, as long as a thread is waiting on a mutex you cannot destroy it legally. Show me a place where the code is accessing the futex after the unlock when there is no locker. -- 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.