public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "anemo at mba dot ocn.ne.jp" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug nptl/13690] New: pthread_mutex_unlock potentially cause invalid access Date: Tue, 14 Feb 2012 14:28:00 -0000 [thread overview] Message-ID: <bug-13690-131@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=13690 Bug #: 13690 Summary: pthread_mutex_unlock potentially cause invalid access Product: glibc Version: 2.15 Status: NEW Severity: normal Priority: P2 Component: nptl AssignedTo: drepper.fsp@gmail.com ReportedBy: anemo@mba.ocn.ne.jp Classification: Unclassified It seems pthread_mutex_unlock() potentially cause invalid access on most platforms (except for i386 and x86_64). In nptl/pthread_mutex_unlock.c, lll_unlock() is called like this: lll_unlock (mutex->__data.__lock, PTHREAD_MUTEX_PSHARED (mutex)); And PTHREAD_MUTEX_PSHARED() is defined like this: # define PTHREAD_MUTEX_PSHARED(m) \ ((m)->__data.__kind & 128) On most platforms, lll_unlock() is defined as a macro like this: #define lll_unlock(lock, private) \ ((void) ({ \ int *__futex = &(lock); \ int __val = atomic_exchange_rel (__futex, 0); \ if (__builtin_expect (__val > 1, 0)) \ lll_futex_wake (__futex, 1, private); \ })) 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. This can happen with this example in pthread_mutex_destroy manual. http://pubs.opengroup.org/onlinepubs/007904875/functions/pthread_mutex_destroy.html ------------------------------------------------------------------------ Destroying Mutexes A mutex can be destroyed immediately after it is unlocked. For example, consider the following code: struct obj { pthread_mutex_t om; int refcnt; ... }; obj_done(struct obj *op) { pthread_mutex_lock(&op->om); if (--op->refcnt == 0) { pthread_mutex_unlock(&op->om); (A) pthread_mutex_destroy(&op->om); (B) free(op); } else (C) pthread_mutex_unlock(&op->om); } In this case obj is reference counted and obj_done() is called whenever a reference to the object is dropped. Implementations are required to allow an object to be destroyed and freed and potentially unmapped (for example, lines A and B) immediately after the object is unlocked (line C). ------------------------------------------------------------------------ In this example, (A) and (B) can be executed in middle of (C) execution. It can happen in this way (explanation by KOSAKI-san): 1) Thread-1) atomic_exchange_rel(0) 2) preempt 3) Thread-2) call mutex_lock(). (ok, it's success) 4) Thread-2) call mutex_unlock() 5) Thread-2) call mutex_destroy() 6) Thread-2) free(mutex) 7) preempt 8) Thread-3) reuse memory of the mutex 9) preempt 10) Thread-1) dereference (mutex)->__data__.__kind Copying __kind to a local variable before atomic_exchange_rel will fix this. -- 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.
next reply other threads:[~2012-02-14 14:28 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-02-14 14:28 anemo at mba dot ocn.ne.jp [this message] 2012-02-14 14:29 ` [Bug nptl/13690] " anemo at mba dot ocn.ne.jp 2012-02-14 15:39 ` carlos at systemhalted dot org 2012-02-14 15:41 ` carlos at systemhalted dot org 2012-02-14 15:42 ` carlos at systemhalted dot org 2012-02-15 6:47 ` ppluzhnikov at google dot com 2012-02-15 13:18 ` anemo at mba dot ocn.ne.jp 2012-02-15 14:35 ` carlos at systemhalted dot org 2012-02-16 5:09 ` bugdal at aerifal dot cx 2012-02-16 14:43 ` anemo at mba dot ocn.ne.jp 2012-02-16 14:47 ` anemo at mba dot ocn.ne.jp 2012-02-16 15:37 ` carlos at systemhalted dot org 2012-02-16 15:41 ` carlos at systemhalted dot org 2012-02-16 16:22 ` bugdal at aerifal dot cx 2012-02-16 16:35 ` carlos at systemhalted dot org 2012-02-17 5:11 ` bugdal at aerifal dot cx 2012-02-17 13:27 ` anemo at mba dot ocn.ne.jp 2012-02-17 16:18 ` carlos at systemhalted dot org 2012-02-17 16:37 ` carlos at systemhalted dot org 2012-02-20 11:42 ` anemo at mba dot ocn.ne.jp 2012-02-22 14:57 ` carlos at systemhalted dot org 2012-02-29 16:54 ` carlos at systemhalted dot org 2012-03-07 10:30 ` drepper.fsp at gmail dot com 2012-03-07 17:53 ` bugdal at aerifal dot cx 2012-03-08 3:23 ` carlos at systemhalted dot org 2012-03-08 5:13 ` bugdal at aerifal dot cx 2012-04-28 9:57 ` coolhair24 at verizon dot net 2012-06-27 22:32 ` jsm28 at gcc dot gnu.org 2012-11-29 15:55 ` carlos_odonell at mentor dot com 2012-12-01 16:43 ` aj at suse dot de 2012-12-03 23:57 ` carlos at systemhalted dot org 2013-10-09 20:14 ` neleai at seznam dot cz 2013-12-18 20:13 ` triegel at redhat dot com 2013-12-18 20:33 ` bugdal at aerifal dot cx 2013-12-18 20:49 ` bugdal at aerifal dot cx 2013-12-20 19:08 ` lopresti at gmail dot com 2013-12-20 19:38 ` carlos at redhat dot com 2013-12-20 20:25 ` triegel at redhat dot com 2013-12-20 22:51 ` bugdal at aerifal dot cx 2014-01-03 9:10 ` kevin.dempsey at aculab dot com 2014-01-06 16:58 ` triegel at redhat dot com 2014-01-06 17:46 ` lopresti at gmail dot com 2014-01-06 20:38 ` triegel at redhat dot com 2014-01-06 20:47 ` bugdal at aerifal dot cx 2014-01-06 21:20 ` triegel at redhat dot com 2014-01-06 21:24 ` bugdal at aerifal dot cx 2014-03-28 1:27 ` dancol at dancol dot org 2014-03-28 20:07 ` tudorb at gmail dot com 2014-06-20 12:23 ` kevin.dempsey at aculab dot com 2014-06-20 18:29 ` triegel at redhat dot com 2014-06-20 19:02 ` bugdal at aerifal dot cx 2014-06-20 19:10 ` bugdal at aerifal dot cx 2014-06-23 3:06 ` bugdal at aerifal dot cx 2014-06-25 14:34 ` triegel at redhat dot com 2014-06-25 16:01 ` bugdal at aerifal dot cx 2014-06-25 17:40 ` triegel at redhat dot com 2014-06-25 18:03 ` bugdal at aerifal dot cx 2014-06-27 7:26 ` fweimer at redhat dot com 2014-08-09 20:38 ` triegel at redhat dot com 2014-08-12 2:29 ` bugdal at aerifal dot cx 2015-01-15 8:45 ` mtk.manpages at gmail dot com 2015-05-30 18:25 ` dancol at dancol dot org 2015-06-03 4:08 ` carlos at redhat dot com 2015-06-03 4:09 ` carlos at redhat dot com 2015-07-14 20:23 ` triegel at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-13690-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).