This is the mail archive of the
mailing list for the glibc project.
Re: [patch] Fix for heap overflow in wscanf (BZ 16618)
- From: Rich Felker <dalias at libc dot org>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Andreas Schwab <schwab at suse dot de>, libc-alpha at sourceware dot org
- Date: Tue, 3 Feb 2015 19:27:49 -0500
- Subject: Re: [patch] Fix for heap overflow in wscanf (BZ 16618)
- Authentication-results: sourceware.org; auth=none
- References: <mvmiofkiqaj dot fsf at hawking dot suse dot de> <CALoOobPyDepfTFp=_y50iKHxAhKV8W+ZkUiV6e-2O=kgpT_08g at mail dot gmail dot com> <87twz4xidl dot fsf at igel dot home> <CALoOobNFbi8csanuAGDwebQeojNWsSqj+6g6w-J94hZ8POOZiw at mail dot gmail dot com> <54D0F628 dot 3000808 at redhat dot com> <20150203180129 dot GP23507 at brightrain dot aerifal dot cx> <54D10E16 dot 7050601 at redhat dot com> <20150203184139 dot GQ23507 at brightrain dot aerifal dot cx> <54D11FE6 dot 9020905 at redhat dot com> <54D163CC dot 30008 at cs dot ucla dot edu>
On Tue, Feb 03, 2015 at 04:11:56PM -0800, Paul Eggert wrote:
> Carlos O'Donell wrote:
> >I'd read the POSIX wording differently.
> Although Rich's interpretation is correct for current POSIX, thanks
> to Eric Blake the next release of POSIX (Issue 8) is planned to
> change this, and to require 'free' to leave errno alone, which as I
> understand it is your preferred interpretation. Please see:
> Because of this, glibc 'free' should not set errno if the user
> invokes 'free' in a conforming way. Setting errno will be a
> conformance bug once Issue 8 comes out, and glibc should be fixed to
> conform well before that. Also, the glibc documentation should be
> changed to discuss this issue. I have filed a glibc bug report to
> that effect, here:
Interesting. Unfortunately this makes it impossible for the
application to observe the "valid memory was unable to be freed"
condition that occurs when you can't split a vma. Formally, the memory
is still freed anyway, so it hardly matters, but it indicates a
critical situation where things are about to blow up for the
application (malloc no longer working, etc.) so conceivably an
application could want to detect and respond to the condition.