From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.emacs.devel Subject: Re: Dumper issue, revisited; invalid realloc/free Date: Wed, 4 Feb 2015 15:02:15 -0500 Message-ID: <20150204200215.GB23507@brightrain.aerifal.cx> References: <20150204175709.GX23507@brightrain.aerifal.cx> <83oap9fppc.fsf@gnu.org> <20150204193732.GZ23507@brightrain.aerifal.cx> <83k2zxfomm.fsf@gnu.org> <20150204194910.GA23507@brightrain.aerifal.cx> <83iofhfo5d.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1423080150 18053 80.91.229.3 (4 Feb 2015 20:02:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Feb 2015 20:02:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 04 21:02:29 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YJ69c-0002H6-Ss for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2015 21:02:29 +0100 Original-Received: from localhost ([::1]:38518 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ69c-0007rn-Cg for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2015 15:02:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ69Z-0007rW-7s for emacs-devel@gnu.org; Wed, 04 Feb 2015 15:02:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJ69U-0006tr-OS for emacs-devel@gnu.org; Wed, 04 Feb 2015 15:02:25 -0500 Original-Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:51461 helo=brightrain.aerifal.cx) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ69Q-0006nv-3O; Wed, 04 Feb 2015 15:02:16 -0500 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1YJ69P-0004Hz-00; Wed, 04 Feb 2015 20:02:15 +0000 Content-Disposition: inline In-Reply-To: <83iofhfo5d.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 216.12.86.13 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182398 Archived-At: 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 > > Cc: emacs-devel@gnu.org > > > > > > > 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