public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>
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	[thread overview]
Message-ID: <bug-13690-131-oghhieq3ki@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-13690-131@http.sourceware.org/bugzilla/>

http://sourceware.org/bugzilla/show_bug.cgi?id=13690

--- Comment #18 from Rich Felker <bugdal at aerifal dot cx> 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.


  parent reply	other threads:[~2012-03-07 17:53 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-14 14:28 [Bug nptl/13690] New: " anemo at mba dot ocn.ne.jp
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 [this message]
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-oghhieq3ki@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: link
Be 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).