From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14640 invoked by alias); 8 Aug 2014 09:59:58 -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 14531 invoked by uid 48); 8 Aug 2014 09:59:48 -0000 From: "fweimer at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug localedata/17187] Out-of-bounds NUL write in iconv_open Date: Fri, 08 Aug 2014 09:59:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: localedata X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fweimer at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: fweimer at redhat dot com 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: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-08/txt/msg00013.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D17187 --- Comment #1 from Florian Weimer --- John Haxby reported this as a functionality bug in 2005: =E2=80=9CThe first problem is that it looks as though the ".so" is appended= to the shared library name after the terminating NUL=E2=80=9D --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-25931-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Aug 08 20:47:50 2014 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 3724 invoked by alias); 8 Aug 2014 20:47:49 -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 Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 3626 invoked by uid 48); 8 Aug 2014 20:47:45 -0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sourceware.org Subject: [Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access Date: Fri, 08 Aug 2014 20:47: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: 2.15 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: carlos at redhat dot com X-Bugzilla-Target-Milestone: 2.18 X-Bugzilla-Flags: review? 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: 2014-08/txt/msg00014.txt.bz2 Content-length: 1432 https://sourceware.org/bugzilla/show_bug.cgi?id=13690 --- Comment #46 from Rich Felker --- I think I have a solution to the spurious-wakes problem using FUTEX_WAKE_OP. The principle is simple: use an atomic compare-and-swap to release the lock, so that we know before releasing (rather than immediately-after, as would be the case with a plain swap) whether there are potentially waiters. Then there are two cases: 1. Waiter count of zero and successful atomic CAS from owned/uncontended state to zero: nothing else to do. 2. Waiter count nonzero or failed atomic CAS (meaning the state changed from owned/uncontended to owned/contended): make a futex syscall with FUTEX_WAKE_OP to perform the atomic unlock AFTER having locked the futex hash buckets, so that a new waiter cannot arrive and thereby get a spurious wake. This design is presently under discussion on the musl libc mailing list, in this thread: http://www.openwall.com/lists/musl/2014/08/08/12 One issue is that the FUTEX_WAKE_OP command takes two addresses, uaddr1 and uaddr2, and performs a potentially expensive futex hash lookup on both. For our purposes we do not need two different addresses, so I think if we pursue this option, we should push the kernel folks to add a special case for uaddr1==uaddr2 that optimizes out the second hash. Thoughts? -- You are receiving this mail because: You are on the CC list for the bug.