From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21959 invoked by alias); 17 Aug 2012 18:52:22 -0000 Received: (qmail 21850 invoked by uid 22791); 17 Aug 2012 18:52:21 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_RW X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Aug 2012 18:52:08 +0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sources.redhat.com Subject: [Bug nptl/14485] New: File corruption race condition in robust mutex unlocking Date: Fri, 17 Aug 2012 18:52:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-08/txt/msg00107.txt.bz2 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.