[PATCH] drm/virtio: reject mappable HOST3D blobs without host-visible memory

[PATCH] drm/virtio: reject mappable HOST3D blobs without host-visible memory

[Henry Martin]

virtio_gpu_resource_create_blob_ioctl() -> verify_blob() validates
blob flags, memory type, context and alignment, but never checks
VIRTGPU_BLOB_FLAG_USE_MAPPABLE against vgdev->has_host_visible.

For blob_mem == VIRTGPU_BLOB_MEM_HOST3D the blob is created via
virtio_gpu_vram_create(), and on a device without host-visible
memory (plain virtio-gpu-pci,blob=on with no hostmem) the failure
comes too late: the GEM object has been allocated, a host resource
id taken and the create_blob command issued when
virtio_gpu_vram_map() returns -EINVAL, and the cleanup calls
virtio_gpu_vram_free(), which is a no-op while bo->created is still
false (the host response has not been processed yet).  Every such
blob creation permanently leaks the vram object and its resource
id; /dev/dri/renderD* is reachable by unprivileged users.

Guest-backed blobs (VIRTGPU_BLOB_MEM_GUEST and
VIRTGPU_BLOB_MEM_HOST3D_GUEST) mmap through the shmem path and do
not need host-visible memory, so only the HOST3D case is rejected.

Commit 036d28db1818a ("drm/virtio: release the GEM object on
virtio_gpu_vram_create() errors") fixed the sibling error paths but
missed this one.  Reject the impossible combination at ioctl entry,
making the failure mode unreachable.

This issue was discovered by Tencent CodeBuddy Security.

Cc: stable@vger.kernel.org
Fixes: 16845c5d5409 ("drm/virtio: implement blob resources: implement vram object")
Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
---
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 81e70a12b3569..e3edade4a62dd 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -533,6 +533,11 @@ static int verify_blob(struct virtio_gpu_device *vgdev,
 			return -EINVAL;
 	}
 
+	if ((rc_blob->blob_flags & VIRTGPU_BLOB_FLAG_USE_MAPPABLE) &&
+	    rc_blob->blob_mem == VIRTGPU_BLOB_MEM_HOST3D &&
+	    !vgdev->has_host_visible)
+		return -EINVAL;
+
 	params->blob_mem = rc_blob->blob_mem;
 	params->size = rc_blob->size;
 	params->blob = true;
-- 
2.43.7

Re: [PATCH] drm/virtio: reject mappable HOST3D blobs without host-visible memory

[sashiko-bot]

> virtio_gpu_resource_create_blob_ioctl() -> verify_blob() validates
> blob flags, memory type, context and alignment, but never checks
> VIRTGPU_BLOB_FLAG_USE_MAPPABLE against vgdev->has_host_visible.
> 
> For blob_mem == VIRTGPU_BLOB_MEM_HOST3D the blob is created via
> virtio_gpu_vram_create(), and on a device without host-visible
> memory (plain virtio-gpu-pci,blob=on with no hostmem) the failure
> comes too late: the GEM object has been allocated, a host resource
> id taken and the create_blob command issued when
> virtio_gpu_vram_map() returns -EINVAL, and the cleanup calls
> virtio_gpu_vram_free(), which is a no-op while bo->created is still
> false (the host response has not been processed yet).  Every such
> blob creation permanently leaks the vram object and its resource
> id; /dev/dri/renderD* is reachable by unprivileged users.
> 
> Guest-backed blobs (VIRTGPU_BLOB_MEM_GUEST and
> VIRTGPU_BLOB_MEM_HOST3D_GUEST) mmap through the shmem path and do
> not need host-visible memory, so only the HOST3D case is rejected.
> 
> Commit 036d28db1818a ("drm/virtio: release the GEM object on
> virtio_gpu_vram_create() errors") fixed the sibling error paths but
> missed this one.  Reject the impossible combination at ioctl entry,
> making the failure mode unreachable.
> 
> This issue was discovered by Tencent CodeBuddy Security.
> 
> Cc: stable@vger.kernel.org
> Fixes: 16845c5d5409 ("drm/virtio: implement blob resources: implement vram object")
> Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261010081059.3096312-1-bsdhenrymartin@gmail.com?part=1

Re: [PATCH] drm/virtio: reject mappable HOST3D blobs without host-visible memory

[Dmitry Osipenko]

On 10/10/26 11:10, Henry Martin wrote:
> virtio_gpu_resource_create_blob_ioctl() -> verify_blob() validates
> blob flags, memory type, context and alignment, but never checks
> VIRTGPU_BLOB_FLAG_USE_MAPPABLE against vgdev->has_host_visible.
> 
> For blob_mem == VIRTGPU_BLOB_MEM_HOST3D the blob is created via
> virtio_gpu_vram_create(), and on a device without host-visible
> memory (plain virtio-gpu-pci,blob=on with no hostmem) the failure
> comes too late: the GEM object has been allocated, a host resource
> id taken and the create_blob command issued when
> virtio_gpu_vram_map() returns -EINVAL, and the cleanup calls
> virtio_gpu_vram_free(), which is a no-op while bo->created is still
> false (the host response has not been processed yet).  Every such

virtio_gpu_cmd_resource_create_blob() is invoked before
virtio_gpu_vram_map() in virtio_gpu_vram_create(), hence bo->created is
always true, how come it's false?

-- 
Best regards,
Dmitry

Re: [PATCH] drm/virtio: reject mappable HOST3D blobs without host-visible memory

[henry martin]

Hi Dmitry,

You're right, thanks for catching this.  bo->created is set
synchronously in virtio_gpu_cmd_resource_create_blob(), so the
unmap/unref completion chain (cmd_unref_cb -> cleanup_object)
releases everything once the host acks.  The leak I described does
not exist - please drop the patch.

Sorry for the noise.

Regards,
Henry

Dmitry Osipenko <dmitry.osipenko@collabora.com> 于2026年10月11日周日 04:19写道：
>
> On 10/10/26 11:10, Henry Martin wrote:
> > virtio_gpu_resource_create_blob_ioctl() -> verify_blob() validates
> > blob flags, memory type, context and alignment, but never checks
> > VIRTGPU_BLOB_FLAG_USE_MAPPABLE against vgdev->has_host_visible.
> >
> > For blob_mem == VIRTGPU_BLOB_MEM_HOST3D the blob is created via
> > virtio_gpu_vram_create(), and on a device without host-visible
> > memory (plain virtio-gpu-pci,blob=on with no hostmem) the failure
> > comes too late: the GEM object has been allocated, a host resource
> > id taken and the create_blob command issued when
> > virtio_gpu_vram_map() returns -EINVAL, and the cleanup calls
> > virtio_gpu_vram_free(), which is a no-op while bo->created is still
> > false (the host response has not been processed yet).  Every such
>
> virtio_gpu_cmd_resource_create_blob() is invoked before
> virtio_gpu_vram_map() in virtio_gpu_vram_create(), hence bo->created is
> always true, how come it's false?
>
> --
> Best regards,
> Dmitry