On 12/7/26 08:48, Marc-André Lureau wrote:
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.
OK, then patch LGTM!
