This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/14485] New: File corruption race condition in robust mutex unlocking
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Fri, 17 Aug 2012 18:52:06 +0000
- Subject: [Bug nptl/14485] New: File corruption race condition in robust mutex unlocking
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=14485
Bug #: 14485
Summary: File corruption race condition in robust mutex
unlocking
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: nptl
AssignedTo: unassigned@sourceware.org
ReportedBy: bugdal@aerifal.cx
CC: drepper.fsp@gmail.com
Classification: Unclassified
The general procedure for unlocking a robust mutex is:
1. Put the mutex address in the "pending" slot of the thread's robust mutex
list.
2. Remove the mutex from the thread's linked list of locked robust mutexes.
3. Low level unlock (clear the futex and possibly wake waiters).
4. Clear the "pending" slot in the thread's robust mutex list.
Suppose between steps 3 and 4, another thread in the same process obtains the
mutex in such a way that it is necessarily the last user of the mutex, then
unlocks, destroys, and frees it. It then calls mmap with MAP_SHARED on a file,
device, or shared memory segment, which happens to be assigned the same address
the robust mutex had, and the file contents at the offset where the futex was
located happen to contain the tid of the first thread that was in between steps
3 and 4 above. Now, suppose the process is immediately killed. The kernel then
sets bit 30 (owner died) at this offset in the mapped file, wrongly trusting
that the pending field in the robust list header still points to a valid robust
mutex.
As far as I can tell, the ONLY solution to this problem is to introduce a
global (within the process) lock on mmap and munmap, and to hold it between
steps 2 and 4 of the robust mutex unlock procedure. The same lock can also be
used to fix bug #13064. To minimize cost, this lock should be a rwlock where
mmap and munmap count as "read" operations (so they don't block one another)
and only the dangerous robust mutex unlock and barrier operations count as
"write" operations.
--
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.