This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix for heap overflow in wscanf (BZ 16618)

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 <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]