From: Gerd Hoffmann <kraxel@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Petr Matousek <pmatouse@redhat.com>,
secalert@redhat.com, qemu-stable@nongnu.org,
qemu-devel@nongnu.org, P J P <ppandit@redhat.com>,
Anthony Liguori <aliguori@amazon.com>,
spice-devel@lists.freedesktop.org
Subject: Re: [Qemu-devel] [CVE-2014-3615 PATCH v2 3/3] spice: make sure we don't overflow ssd->buf
Date: Fri, 05 Sep 2014 10:58:11 +0200 [thread overview]
Message-ID: <1409907491.20018.5.camel@nilsson.home.kraxel.org> (raw)
In-Reply-To: <54096BC2.7070102@redhat.com>
Hi,
> I can't track this back far enough. I'd feel safer if you checked that
> the multiplication can't overflow even in uint64_t.
Effectively it comes from the emulated graphics hardware (anything in
hw/display/*). The gfx emulation must make sure that the framebuffer
fits into the video memory, which in turn pretty much implies that we
can't overflow uint64_t. I think even uint32_t can't overflow with the
gfx hardware we are emulating today.
> (5) Instead, you really need to make sure that the very first
> multiplication fits in a signed int:
Makes sense. I think it is easier to just multiply in 64bit, then check
the result is small enougth (new patch attached).
> > /* display listener callbacks */
> > @@ -495,7 +503,7 @@ static void interface_get_init_info(QXLInstance *sin, QXLDevInitInfo *info)
> > info->num_memslots = NUM_MEMSLOTS;
> > info->num_memslots_groups = NUM_MEMSLOTS_GROUPS;
> > info->internal_groupslot_id = 0;
> > - info->qxl_ram_size = ssd->bufsize;
> > + info->qxl_ram_size = 16 * 1024 * 1024;
> > info->n_surfaces = ssd->num_surfaces;
> > }
spice-server doesn't do anything with it, other than passing to
spice-client. Not fully sure what spice-client uses this for, maybe as
some kind of hint for resource management. Maybe not at all.
It surely doesn't matter at all for ssd->buf size.
cheers,
Gerd
next prev parent reply other threads:[~2014-09-05 8:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-04 7:04 [Qemu-devel] [CVE-2014-3615 PATCH v2 0/3] vbe: bochs dispi interface fixes Gerd Hoffmann
2014-09-04 7:04 ` [Qemu-devel] [CVE-2014-3615 PATCH v2 1/3] vbe: make bochs dispi interface return the correct memory size with qxl Gerd Hoffmann
2014-09-04 7:04 ` [Qemu-devel] [CVE-2014-3615 PATCH v2 2/3] vbe: rework sanity checks Gerd Hoffmann
2014-09-04 7:04 ` [Qemu-devel] [CVE-2014-3615 PATCH v2 3/3] spice: make sure we don't overflow ssd->buf Gerd Hoffmann
2014-09-05 7:52 ` Laszlo Ersek
2014-09-05 8:58 ` Gerd Hoffmann [this message]
2014-09-05 9:06 ` Laszlo Ersek
2014-09-05 9:33 ` Gerd Hoffmann
2014-09-05 10:15 ` Laszlo Ersek
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=1409907491.20018.5.camel@nilsson.home.kraxel.org \
--to=kraxel@redhat.com \
--cc=aliguori@amazon.com \
--cc=lersek@redhat.com \
--cc=pmatouse@redhat.com \
--cc=ppandit@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=secalert@redhat.com \
--cc=spice-devel@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).