From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2450 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: stdio self-synchronized destruction: does it need fixing? Date: Mon, 10 Dec 2012 13:05:09 -0500 Message-ID: <20121210180508.GA2313@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1355162725 16206 80.91.229.3 (10 Dec 2012 18:05:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Dec 2012 18:05:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2451-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 10 19:05:39 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Ti7jU-0006Ds-57 for gllmg-musl@plane.gmane.org; Mon, 10 Dec 2012 19:05:36 +0100 Original-Received: (qmail 26358 invoked by uid 550); 10 Dec 2012 18:05:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 26350 invoked from network); 10 Dec 2012 18:05:22 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2450 Archived-At: Hi all, Question about an issue that seems purely theoretical: self-synchronized destruction of stdio FILEs. Does anything need to be fixed? The basic self-synchronized destruction scenario that affects all synchronization primitives is: Thread A is waiting to acquire the resource with the knowledge that there is presently at most one other thread using it. Thread B releases the lock, then checks to see if there are any waiters to wake up. But between these two steps, it's possible that thread A already woke up and destroyed the object, in which case, reading the waiters field is an invalid read. glibc has a number of such bugs, but I fixed most of them in musl a long time ago. (Note that this is a race condition that takes somewhere on the order of years to hit, unless you artificially poke at the timing; that's why it doesn't get much attention.) Anyway, I recently realized that musl still has the issue for stdio FILE streams. If thread B is holding a lock with flockfile and thread A calls fclose on the locked stream, it's possible that when thread B unlocks the stream, thread A gets to free it before thread B can check to see if there are waiters that need to be woken. "Fixing" the issue would not be too hard, but since it's nontrivial, I'd like to consider whether the fix is actually necessary. Unlike mutexes or semaphores, FILEs do not exist in application-controlled memory. The allocation of FILE structues is always performed by libc, and always happens via malloc with a small-size allocation, which means the memory is managed as part of the heap and never unmapped once it's mapped. Thus, as far as I can tell, the worst that can happen is a read-only access to memory no longer owned by the FILE, but that's still valid, and in this case, it doesn't matter whether a wakeup futex event is generated, since there can be no waiters; spurious wakeup events are harmless here. Any thoughts by others on the matter? Rich