Re: [PATCH] hw/display/virtio-gpu: validate blob iov size in create_blob

Akihiko Odaki <[email protected]> Sat, 1 Aug 2026 16:34:15 +0900
Newsgroups org.nongnu.qemu-devel
Message-ID <[email protected]>
On 2026/07/30 0:19, Thomas Huth wrote:
> On 24/07/2026 08.26, Akihiko Odaki wrote:
>> On 2026/07/24 12:57, [email protected] wrote:
>>> From: Marc-André Lureau <[email protected]>
>>>
>>> virtio_gpu_resource_create_blob() stores the guest-controlled blob_size
>>> without checking it against the total size of the iov backing entries.
>>> Since both values are independently guest-controlled, a malicious guest
>>> can set blob_size much larger than the actual iov backing. Subsequent
>>> SET_SCANOUT_BLOB checks bounds against the inflated blob_size, allowing
>>> a pixman surface to be created over the undersized buffer. Any display
>>> refresh then reads past the actual allocation, potentially crashing
>>> QEMU or leaking host memory contents depending on the backing type.
>>>
>>> Reject the resource early when the iov backing is smaller than the
>>> declared blob_size.
>>
>> The same invariant also needs to be enforced when backing is supplied
>> by VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING and when blob migration state
>> is loaded. Otherwise, newly attached backing or state received from an
>> older source can bypass this fix.
>>
>> The check cannot be unconditional at resource creation, however. The
>> specification permits nr_entries == 0 so that backing can be attached
>> later for swap-in/swap-out. As written, this patch rejects that valid
>> request:
>>
>>  > To facilitate drivers that support swap-in and swap-out, nr_entries
>>  > may be zero and VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING may be
>>  > subsequently used. VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING may be
>>  > used to unassign memory entries.
>>
>> https://docs.oasis-open.org/virtio/virtio/v1.3/virtio- 
>> v1.3.html#x1-4120008
> 
> The patch that is proposed in https://gitlab.com/qemu-project/qemu/-/ 
> work_items/4112 also checks for res->iov_cnt > 0 ... would that fix your 
> concerns?

Yes, it would. Marc-André has since sent v3, which addresses my
concerns.

Regards,
Akihiko Odaki

> 
>   Thomas
> 
> 
> 
>>
>>>
>>> Fixes: CVE-2026-66021
>>> Fixes: e0933d91b1cd ("virtio-gpu: Add virtio_gpu_resource_create_blob")
>>> Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3945
>>> Reported-by: "sundayjiang(蒋浩天)" <[email protected]>
>>> Signed-off-by: Marc-André Lureau <[email protected]>
>>> ---
>>>   hw/display/virtio-gpu.c | 10 ++++++++++
>>>   1 file changed, 10 insertions(+)
>>>
>>> diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
>>> index eac039c3c366..cc6dbd116618 100644
>>> --- a/hw/display/virtio-gpu.c
>>> +++ b/hw/display/virtio-gpu.c
>>> @@ -372,6 +372,16 @@ static void 
>>> virtio_gpu_resource_create_blob(VirtIOGPU *g,
>>>           return;
>>>       }
>>> +    if (iov_size(res->iov, res->iov_cnt) < res->blob_size) {
>>> +        qemu_log_mask(LOG_GUEST_ERROR,
>>> +                      "%s: backing storage smaller than blob size\n",
>>> +                      __func__);
>>> +        cmd->error = VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER;
>>> +        virtio_gpu_cleanup_mapping(g, res);
>>> +        g_free(res);
>>> +        return;
>>> +    }
>>> +
>>>       virtio_gpu_init_udmabuf(res);
>>>       QTAILQ_INSERT_HEAD(&g->reslist, res, next);
>>>   }
>>
>>
>