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 13:06: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>
On 02/03/2015 01:01 PM, Rich Felker wrote:
> On Tue, Feb 03, 2015 at 11:24:08AM -0500, Carlos O'Donell wrote:
>> On 02/02/2015 01:59 PM, Paul Pluzhnikov wrote:
>>> On Mon, Feb 2, 2015 at 10:45 AM, Andreas Schwab <schwab@suse.de> wrote:
>>> \
>>>>> + __set_errno (ENOMEM); \
>>>>
>>>> You already have a meaningful errno from the failed realloc.
>>>
>>> I see. And we are sure that "free(old)" will not touch errno?
>>
>> Yes, free can never fail. If free were to touch errno it would be a bug,
>> or would only happen in cases of undefined behaviour.
>
> free can make a syscall that will set errno unless you suppress this
> behavior -- munmap can fail due to inability to split an existing vma
> due to hitting the vma limit or simply a kernel oom condition. In this
> case I suspect you get the result you want, ENOMEM, anyway, but in
> general if you want free to have a contract not to set errno, that
> requires some attention, and it's almost surely not satisfied if
> applications are allowed to replace free...
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.
Cheers,
Carlos.