All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Prasad J Pandit <pjp@fedoraproject.org>,
	patches@linaro.org, Jan Kiszka <jan.kiszka@siemens.com>,
	jasowang@redhat.com, qemu-devel@nongnu.org,
	liqsub1 <liqsub1@163.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [Qemu-devel] [PATCH for-3.0] slirp: Correct size check in m_inc()
Date: Tue, 7 Aug 2018 13:58:19 +0100	[thread overview]
Message-ID: <20180807125819.GP7335@redhat.com> (raw)
In-Reply-To: <20180807125223.GF2556@work-vm>

On Tue, Aug 07, 2018 at 01:52:24PM +0100, Dr. David Alan Gilbert wrote:
> * Peter Maydell (peter.maydell@linaro.org) wrote:
> > The data in an mbuf buffer is not necessarily at the start of the
> > allocated buffer. (For instance m_adj() allows data to be trimmed
> > from the start by just advancing the pointer and reducing the length.)
> > This means that the allocated buffer size (m->m_size) and the
> > amount of space from the m_data pointer to the end of the
> > buffer (M_ROOM(m)) are not necessarily the same.
> > 
> > Commit 864036e251f54c9 tried to change the m_inc() function from
> > taking the new allocated-buffer-size to taking the new room-size,
> > but forgot to change the initial "do we already have enough space"
> > check. This meant that if we were trying to extend a buffer which
> > had a leading gap between the buffer start and the data, we might
> > incorrectly decide it didn't need to be extended, and then
> > overrun the end of the buffer, causing memory corruption and
> > an eventual crash.
> > 
> > Change the "already big enough?" condition from checking the
> > argument against m->m_size to checking against M_ROOM().
> > This only makes a difference for the callsite in m_cat();
> > the other three callsites all start with a freshly allocated
> > mbuf from m_get(), which will have m->m_size == M_ROOM(m).
> > 
> > Fixes: 864036e251f54c9

IIUC, this changeset was a security fix for CVE-2018-11806.

Given that the fix was flawed and allowed guest to crash the host
with a new buffer overrun, it seems we need to get a new CVE allocated
too.

> > Fixes: https://bugs.launchpad.net/qemu/+bug/1785670
> > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> 
> Tested-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> 
> > ---
> >  slirp/mbuf.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/slirp/mbuf.c b/slirp/mbuf.c
> > index 0c189e1a7bf..1b7868355a3 100644
> > --- a/slirp/mbuf.c
> > +++ b/slirp/mbuf.c
> > @@ -154,7 +154,7 @@ m_inc(struct mbuf *m, int size)
> >      int datasize;
> >  
> >      /* some compilers throw up on gotos.  This one we can fake. */
> > -    if (m->m_size > size) {
> > +    if (M_ROOM(m) > size) {
> >          return;
> >      }
> >  
> > -- 
> > 2.17.1
> > 
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

  reply	other threads:[~2018-08-07 12:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-07 11:45 [Qemu-devel] [PATCH for-3.0] slirp: Correct size check in m_inc() Peter Maydell
2018-08-07 11:54 ` Samuel Thibault
2018-08-07 12:52 ` Dr. David Alan Gilbert
2018-08-07 12:58   ` Daniel P. Berrangé [this message]
2018-08-07 13:07     ` Thomas Huth
2018-08-07 13:09       ` Daniel P. Berrangé
2018-08-07 13:47         ` Peter Maydell
2018-08-07 15:47           ` Markus Armbruster
2018-08-07 15:58             ` Peter Maydell
2018-08-07 13:45 ` Peter Maydell
2018-08-09 11:12 ` Dr. David Alan Gilbert
2018-08-09 11:25   ` Peter Maydell
2018-08-09 11:32     ` Dr. David Alan Gilbert
2018-08-09 21:54       ` Samuel Thibault
2018-08-10  9:02         ` Peter Maydell
2018-08-10  9:08           ` Samuel Thibault
2018-08-10  9:13             ` Peter Maydell

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=20180807125819.GP7335@redhat.com \
    --to=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jasowang@redhat.com \
    --cc=liqsub1@163.com \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=pjp@fedoraproject.org \
    --cc=qemu-devel@nongnu.org \
    --cc=samuel.thibault@ens-lyon.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.