[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-stable] [CVE-2014-3615 PATCH v2 3/3] spice: make sure we don't
From: |
Gerd Hoffmann |
Subject: |
Re: [Qemu-stable] [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 |
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