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: Rich Felker <dalias at libc dot org>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: 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 13:41:39 -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>
On Tue, Feb 03, 2015 at 01:06:14PM -0500, Carlos O'Donell wrote:
> 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.
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.
Rich