From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1DeyzL-0002Zt-E7
	for qemu-devel@nongnu.org; Sun, 05 Jun 2005 13:32:43 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1DeyzD-0002P3-E4
	for qemu-devel@nongnu.org; Sun, 05 Jun 2005 13:32:35 -0400
Received: from [129.104.30.34] (helo=mx1.polytechnique.org)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1DeytZ-0002kz-FH
	for qemu-devel@nongnu.org; Sun, 05 Jun 2005 13:26:45 -0400
Message-ID: <42A33515.7010108@bellard.org>
Date: Sun, 05 Jun 2005 19:23:33 +0200
From: Fabrice Bellard <fabrice@bellard.org>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] Fix for a malloc heap corruption problem
	in	the slirp network code
References: <200505170804.j4H84mg4018307@imap3.tools.intra>
In-Reply-To: <200505170804.j4H84mg4018307@imap3.tools.intra>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Juergen Keil <jk@tools.de>, qemu-devel@nongnu.org

Juergen Keil wrote:
> Compiling inside a NetBSD 1.5 qemu guest OS (source files are located
> on an NFS filesystem mounted from the Solaris host OS) crashes qemu
> with a malloc heap corruption error, when the slirp user mode
> networking code is in use.
> [...]

> Using the "electric fence" memory allocator, the location of the data
> corruption can be narrowed down to the destination address in the memcpy
> call in slirp/mbuf.c, function m_cat():
> 
>     void
>     m_cat(m, n)
> 	register struct mbuf *m, *n;
>     {
> 	/*
> 	 * If there's no room, realloc
> 	 */
> 	if (M_FREEROOM(m) < n->m_len)
> 		m_inc(m,m->m_size+MINCSIZE);

First this code is incorrect : it increases the size by MINCSIZE which 
can be smaller than the required size.

> 	
> 	memcpy(m->m_data+m->m_len, n->m_data, n->m_len);  <<<< this memcpy 
> 							  corrupts the malloc
> 							  heap
>         ....
>     }
> 
> 
> The problem is apparently in m_inc(), when an mbuf with an external
> data buffer is resized.  After resizing the mbuf, the m_data member
> still points into the old buffer, before is was reallocated.  For some
> reason, the code to re-adjust the m_data pointer is present in the M_EXT
> case in m_inc(), but is commented out. (With a bit of luck, realloc
> might be able to adjust the size of the memory block in place; but
> slirp shouldn't rely on this)
> 
> Fix: Adjust mbuf->m_data after a realloc of the external data buffer

OK. Does someone knows why this code was suppressed ?

Fabrice.