[Bug nptl/14485] New: File corruption race condition in robust mutex unlocking

["bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>]

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.