From owner-freebsd-bugs  Wed Aug 27 23:10:04 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA10450
          for bugs-outgoing; Wed, 27 Aug 1997 23:10:04 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA10437;
          Wed, 27 Aug 1997 23:10:01 -0700 (PDT)
Date: Wed, 27 Aug 1997 23:10:01 -0700 (PDT)
Message-Id: <199708280610.XAA10437@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: Tim Vanderhoek <hoek@hwcn.org>
Subject: Re: bin/4403: vasprintf (3) corrupts memory
Reply-To: Tim Vanderhoek <hoek@hwcn.org>
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR bin/4403; it has been noted by GNATS.

From: Tim Vanderhoek <hoek@hwcn.org>
To: Andrew Cagney <cagney@tpgi.com.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, GNATS Management <gnats@FreeBSD.ORG>,
        freebsd-bugs@hub.freebsd.org
Subject: Re: bin/4403: vasprintf (3) corrupts memory
Date: Thu, 28 Aug 1997 02:01:39 -0400 (EDT)

 [dup and prev. fixed pr -- close]
 
 [Out of curiosity, is it correct to keep the cc to gnats
 management here?  I typically delete it, but people typically
 delete this otherwise.]
 
 On Thu, 28 Aug 1997, Andrew Cagney wrote:
 
 > >Number:         4403
 > >Category:       bin
 > >Synopsis:       vasprintf (3) corrupts memory
 [...]
 > >Environment:
 > 
 > 	Probably also in FreeBSD 2.2.2.
 
 Yes.  But not anything beyond.  You could have tried getting a
 new copy of vasprintf.c from -current.  The only reason it's in
 2.2.2 is because people (committers?) don't fix pr's when they're
 submitted.  Kudos to those who have recently taken the time to
 close as many pr's as possible.
 
 
 > 	vasprintf.c:vasprintf() unconditionally appends a null
 > 	character to its buffer.  Since vasprintf.c:writehook()
 > 	allows the buffer to completely fill (left == 0), that store
 > 	can blat memory beyound the buffers bounds.
 
 This bug has been fixed.  The pr can be closed.
 
 
 > >How-To-Repeat:
 > 
 > 	Combine FreeBSD with GDB/mmalloc and wait for gdb to panic?
 
 The original pr for this bug includes a how-to-repeat .c program.
 The pr is closed, of course.  :)
 
 
 > or	2 - (better?) re-order the tail of vasprintf so that it reads:
 > 
 > 	*str = realloc(h.base, (size_t)(h.size - h.left + 1));
 > 	if (*str == NULL)	/* failed to realloc it to actual size */
 > 		*str = h.base;	/* return oversize buffer */
 > 	(*str)[h.size - h.left] = '\0';
 > 	return (ret);
 
 No, that could still overrun memory if realloc() fails and 
 h.left == 0.
 
 
 --
 Outnumbered?  Maybe.  Outspoken?  Never!
 tIM...HOEk