Re: [PATCH] vhost-user-gpu: fix integer overflow in buffer allocation

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!