From: sashiko-bot@kernel.org
To: "Henry Martin" <bsdhenrymartin@gmail.com>
Cc: dri-devel@lists.freedesktop.org,
"Michael S. Tsirkin" <mst@redhat.com>,
virtualization@lists.linux.dev,
"Eugenio Perez" <eperezma@redhat.com>
Subject: Re: [PATCH] drm/virtio: reject mappable HOST3D blobs without host-visible memory
Date: Sat, 10 Oct 2026 08:25:37 +0000 [thread overview]
Message-ID: <sashiko-outbox-166346@kernel.org> (raw)
In-Reply-To: <20261010081059.3096312-1-bsdhenrymartin@gmail.com>
> 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
next prev parent reply other threads:[~2026-10-10 8:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 8:10 [PATCH] drm/virtio: reject mappable HOST3D blobs without host-visible memory Henry Martin
2026-10-10 8:25 ` sashiko-bot [this message]
2026-10-10 20:19 ` Dmitry Osipenko
2026-10-11 4:24 ` henry martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-166346@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bsdhenrymartin@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=eperezma@redhat.com \
--cc=mst@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=virtualization@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.