From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24025 invoked by alias); 10 Feb 2015 00:18:47 -0000 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 Received: (qmail 23920 invoked by uid 48); 10 Feb 2015 00:18:44 -0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sourceware.org Subject: [Bug nptl/14485] File corruption race condition in robust mutex unlocking Date: Tue, 10 Feb 2015 00:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: unspecified 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-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-02/txt/msg00125.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=14485 --- Comment #8 from Rich Felker --- In reply to comment 4, this issue can be avoided by applications in at least two ways: 1. Use a separate mapping of the shared synchronization object for each user/thread that might want to unmap it. 2. Use a separate synchronization object local to the process to synchronize unmapping of the shared mutex. Since the only way you'd have multiple threads in the same process accessing the shared synchronization object is by storing the pointer to the (mapping containing the) shared mutex in some process-local object that's shared between threads, it seems natural that you would already be synchronizing access to this memory with another mutex (or other synchronization object) stored with the pointer. So approach 2 seems like it's always practical, probably doesn't involve any new synchronization, and likely makes it unnecessary/useless to support self-synchronized unmapping. On the other hand, it may not actually be any harder to support self-synchronized unmapping than to support self-synchronized destruction+unmapping, which almost certainly needs to be supported. -- You are receiving this mail because: You are on the CC list for the bug.