This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Wed, 07 Mar 2012 17:52:03 +0000
- Subject: [Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access
- Auto-submitted: auto-generated
- References: <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.