This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [patch] Fix for heap overflow in wscanf (BZ 16618)
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, Andreas Schwab <schwab at suse dot de>, libc-alpha at sourceware dot org
- Date: Tue, 03 Feb 2015 14:22:14 -0500
- Subject: Re: [patch] Fix for heap overflow in wscanf (BZ 16618)
- Authentication-results: sourceware.org; auth=none
- References: <CALoOobPgvuBLTk4GzOchr792MHNi1yLgsO5Jqf8MPvY+bk544Q at mail dot gmail dot com> <20150202050906 dot GF23507 at brightrain dot aerifal dot cx> <CALoOobP5yEqB-oKUvPVJm0znonYJ_iM1q_uFBNT2sRojBguJ-A at mail dot gmail dot com> <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>
On 02/03/2015 01:41 PM, Rich Felker wrote:
>> I would consider all of these things bugs and particularly in the use
>> case of the user-provide free() a conformance issue for modifying errno
>> without there being an error.
>
> ISO C and POSIX explicitly permit any function to modify errno on
> success as long as they don't set it to zero. free always succeeds, so
> it's always valid for free to clobber errno. This is not a conformance
> issue. If you assume free does not modify errno, that's a non-portable
> assumption from the application side and a flawed assumption from the
> glibc side assuming you allow replacement of malloc/free.
I had not interpreted the wording as you paraphrase it, but I can see
how it could be interpreted like that.
My expectation had simply been that functions that don't define any
conditions under which errno is defined, would by this fact not have
any need to modify errno.
Thus without a need to modify errno I conflated that to mean "should
not modify errno," but the truth is they can actually do the opposite
and have free reign to change the value at will (except 0).
So we have:
* free() doesn't say it sets errno, therefore errno is undefined until
it is changed by the next function call or application code
* errno after success is unspecified because the description of free()
does not say anything about errno on success
* errno can't be examined because free() never describes when it might
be valid to do so
* errno is not set to 0 after a successful call to free()
So free() is, under the standard, free to write any value to errno
except 0, and it is the application that may not examine errno.
Thanks, I'd read the POSIX wording differently.
Cheers,
Carlos.