emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dumper issue, revisited; invalid realloc/free


From: Rich Felker
Subject: Re: Dumper issue, revisited; invalid realloc/free
Date: Wed, 4 Feb 2015 15:02:15 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Feb 04, 2015 at 09:54:38PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 4 Feb 2015 14:49:10 -0500
> > From: Rich Felker <address@hidden>
> > Cc: address@hidden
> > 
> > > > > Or that the libc memory allocation routines can gracefully handle
> > > > > these situations.
> > > > 
> > > > I would not consider that "graceful". If they detect that the pointer
> > > > passed to realloc or free is invalid, the only reasonable behavior is
> > > > to abort.
> > > 
> > > They could do exactly what you planned to do: ignore the 'free' part
> > > and only allocate a new block.
> > 
> > This behavior does not make sense in system malloc
> 
> Of course, it does: to support Emacs.  glibc is still a GNU project,
> isn't it?

glibc is maintained by a consensus-based community these days, and I
don't think sacrificing the ability to detect serious memory
corruption that likely indicates an exploit attempt for the sake of
satisfying emacs' invalid assumptions about malloc would be popular.
The same checks can be made on the emacs side before calling the
underlying realloc/free, and this way they don't compromise efforts to
harden other applications.

Rich



reply via email to

[Prev in Thread] Current Thread [Next in Thread]