All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Val Packett" <val@invisiblethingslab.com>
Cc: virtualization@lists.linux.dev, dri-devel@lists.freedesktop.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Eugenio Perez" <eperezma@redhat.com>
Subject: Re: [PATCH] drm/virtio: do not enforce blob_alignment in cross-domain contexts
Date: Tue, 06 Oct 2026 00:53:52 +0000	[thread overview]
Message-ID: <20261006005352.77E821F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261006004044.2242154-1-val@invisiblethingslab.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] drm/virtio: NULL pointer dereference in verify_blob() when 3D features are disabled
- [Medium] drm/virtio: data race when reading vfpriv->context_init in verify_blob()
--

commit e614dba4f51f24b9effac7458783e310e89be777
Author: Val Packett <val@invisiblethingslab.com>
drm/virtio: do not enforce blob_alignment in cross-domain contexts

The commit prevents enforcing blob_alignment requirements in cross-domain
contexts, as resources created there are arbitrary shared system memory files
like Wayland keymaps.

> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -540,6 +540,8 @@ static int verify_blob(struct virtio_gpu_device *vgdev,
>  	params->blob_hints = rc_blob->blob_hints;
>  
>  	if (vgdev->has_blob_alignment &&
> +	    (vfpriv->context_init & VIRTIO_GPU_CONTEXT_INIT_CAPSET_ID_MASK) !=
> +	    VIRTIO_GPU_CAPSET_CROSS_DOMAIN &&

[Severity: Critical]
If a virtio-gpu device advertises VIRTIO_GPU_F_RESOURCE_BLOB and
VIRTIO_GPU_F_BLOB_ALIGNMENT but not VIRTIO_GPU_F_VIRGL, could this cause a
NULL pointer dereference?

In this scenario, virtio_gpu_driver_open() returns successfully but leaves
file->driver_priv (which is passed as vfpriv) as NULL. When userspace then
calls DRM_IOCTL_VIRTGPU_RESOURCE_CREATE_BLOB with VIRTGPU_BLOB_MEM_GUEST,
verify_blob() is reached without aborting on the has_virgl_3d check.

This newly added code will then unconditionally dereference
vfpriv->context_init because vgdev->has_blob_alignment is true, causing a
kernel panic. Is there a way to verify vfpriv is not NULL before accessing
context_init?

[Severity: Medium]
Does this introduce a data race when reading context_init?

This accesses the lock-protected context_init field without acquiring
vfpriv->context_lock. A lockless read of context_init could read a partially
written bitmask if updated concurrently, leading to incorrectly enforcing or
bypassing blob alignment checks and returning spurious -EINVAL to userspace.

This could happen if userspace calls DRM_IOCTL_VIRTGPU_CONTEXT_INIT and
DRM_IOCTL_VIRTGPU_RESOURCE_CREATE_BLOB concurrently on the same file
descriptor.

>  	    !IS_ALIGNED(params->size, vgdev->blob_alignment))
>  		return -EINVAL;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261006004044.2242154-1-val@invisiblethingslab.com?part=1

      reply	other threads:[~2026-10-06  0:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-06  0:34 [PATCH] drm/virtio: do not enforce blob_alignment in cross-domain contexts Val Packett
2026-10-06  0:53 ` sashiko-bot [this message]

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=20261006005352.77E821F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eperezma@redhat.com \
    --cc=mst@redhat.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=val@invisiblethingslab.com \
    --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.