Hi

On Fri, Jul 10, 2026 at 7:35 PM Philippe Mathieu-Daudé
<[email protected]> wrote:
>
> On 10/7/26 15:47, [email protected] wrote:
> > From: Marc-André Lureau <[email protected]>
> >
> > A malicious guest can trigger a heap buffer overflow in the
> > vhost-user-gpu backend by sending a VIRTIO_GPU_CMD_RESOURCE_CREATE_2D
> > with large width and height values (e.g. 65537x65537). The allocation
> > size width * height * 4 silently wraps in uint32_t arithmetic,
> > resulting in a much smaller allocation than expected. Subsequent
> > VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D writes past the heap buffer.
> >
> > The in-tree virtio-gpu device (hw/display/virtio-gpu.c) already handles
> > this via calc_image_hostmem() with uint64_t arithmetic and an overflow
> > check. Apply the same approach to the vhost-user-gpu contrib backend:
> >
> > - Add an overflow check in vugbm_buffer_create() rejecting dimensions
> >    where width * height * 4 exceeds UINT32_MAX
> > - Promote the size arithmetic to uint64_t in mem_alloc_bo() and
> >    udmabuf_get_size()
> > - Check the return value of vugbm_buffer_create() in
> >    vg_resource_create_2d(), which was previously ignored
> >
> > Fixes: CVE-2026-15264
> > Reported-by: "Vulnerability Report" <[email protected]>
> > Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3940
> > Signed-off-by: Marc-Andre Lureau <[email protected]>
> > ---
> >   contrib/vhost-user-gpu/vhost-user-gpu.c |  8 +++++++-
> >   contrib/vhost-user-gpu/vugbm.c          | 11 +++++++++--
> >   2 files changed, 16 insertions(+), 3 deletions(-)
>
>
> > diff --git a/contrib/vhost-user-gpu/vugbm.c b/contrib/vhost-user-gpu/vugbm.c
> > index 503d0a4566f..710d5452977 100644
> > --- a/contrib/vhost-user-gpu/vugbm.c
> > +++ b/contrib/vhost-user-gpu/vugbm.c
> > @@ -13,7 +13,7 @@
> >   static bool
> >   mem_alloc_bo(struct vugbm_buffer *buf)
> >   {
> > -    buf->mmap = g_malloc(buf->width * buf->height * 4);
> > +    buf->mmap = g_malloc((uint64_t)buf->width * buf->height * 4);
>
> Just curious, would this also work safely?
>
>         buf->mmap = g_malloc_n(4, buf->width * buf->height);
>
> The GLib description is:
>
>    This function is similar to g_malloc(),
>    allocating (n_blocks * n_block_bytes) bytes,
>    but care is taken to detect possible overflow
>    during multiplication.

Yes, that would be similar.

thanks

Reply via email to