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); >>> } >> >> >