[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