[Bug localedata/17187] Out-of-bounds NUL write in iconv_open

["fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17187

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
John Haxby reported this as a functionality bug in 2005:

“The first problem is that it looks as though the ".so" is appended to the
shared library name after the terminating NUL”

<https://www.sourceware.org/ml/libc-alpha/2005-12/msg00091.html>

-- 
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: <glibc-bugs-return-25931-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
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: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
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" <sourceware-bugzilla@sourceware.org>
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: <bug-13690-131-XWMcbUuBHf@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-13690-131@http.sourceware.org/bugzilla/>
References: <bug-13690-131@http.sourceware.org/bugzilla/>
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\x13690

--- Comment #46 from Rich Felker <bugdal at aerifal dot cx> ---
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.