qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] display: virtio-gpu-3d: check virgl capabilitie


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH] display: virtio-gpu-3d: check virgl capabilities max_size
Date: Tue, 13 Dec 2016 12:17:41 +0100

On Di, 2016-12-13 at 12:44 +0530, P J P wrote:
> From: Prasad J Pandit <address@hidden>
> 
> Virtio GPU device while processing 'VIRTIO_GPU_CMD_GET_CAPSET'
> command, retrieves the maximum capabilities size to fill in the
> response object. It continues to fill in capabilities even if
> retrieved 'max_size' is zero(0), thus resulting in OOB access.
> Add check to avoid it.

Hmm?  Did you see this happing in practice?

> diff --git a/hw/display/virtio-gpu-3d.c b/hw/display/virtio-gpu-3d.c
> index 758d33a..fbfb39f 100644
> --- a/hw/display/virtio-gpu-3d.c
> +++ b/hw/display/virtio-gpu-3d.c
> @@ -371,11 +371,12 @@ static void virgl_cmd_get_capset(VirtIOGPU *g,
>      virgl_renderer_get_cap_set(gc.capset_id, &max_ver,
>                                 &max_size);

This is not the guest returning the size, it is the host renderer
library saying how much space it needs ...

>      resp = g_malloc(sizeof(*resp) + max_size);
> -
> -    resp->hdr.type = VIRTIO_GPU_RESP_OK_CAPSET;
> -    virgl_renderer_fill_caps(gc.capset_id,
> -                             gc.capset_version,
> -                             (void *)resp->capset_data);

... and here the renderer fills the qemu-allocated space with the actual
data.

Can't see anything wrong here.  It's not that we process untrusted data
without checking.  If a buffer overflow happens here this would clearly
be a bug in the virglrenderer library, because the size advertised and
the size actually needed mismatch.

cheers,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]