Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Aug 1997 23:10:01 -0700 (PDT)
From:      Tim Vanderhoek <hoek@hwcn.org>
To:        freebsd-bugs
Subject:   Re: bin/4403: vasprintf (3) corrupts memory
Message-ID:  <199708280610.XAA10437@hub.freebsd.org>

next in thread | raw e-mail | index | archive | help
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
 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708280610.XAA10437>