From: Fabrice Bellard <fabrice@bellard.org>
To: Juergen Keil <jk@tools.de>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Fix for a malloc heap corruption problem in the slirp network code
Date: Sun, 05 Jun 2005 19:23:33 +0200 [thread overview]
Message-ID: <42A33515.7010108@bellard.org> (raw)
In-Reply-To: <200505170804.j4H84mg4018307@imap3.tools.intra>
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.
next prev parent reply other threads:[~2005-06-05 17:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-17 8:04 [Qemu-devel] [PATCH] Fix for a malloc heap corruption problem in the slirp network code Juergen Keil
2005-06-05 17:23 ` Fabrice Bellard [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-06-06 9:06 Juergen Keil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42A33515.7010108@bellard.org \
--to=fabrice@bellard.org \
--cc=jk@tools.de \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.