All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Rob Clark" <robin.clark@oss.qualcomm.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v5 04/10] drm/msm/a6xx: Access VM directly in submit path
Date: Thu, 16 Jul 2026 20:43:07 +0000	[thread overview]
Message-ID: <20260716204308.425001F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260716201538.365824-5-robin.clark@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Direct access to uninitialized `ctx->vm` during early ioctl validation causes a NULL pointer dereference.
--

--- Patch [4]: [PATCH v5 04/10] drm/msm/a6xx: Access VM directly in submit path ---
commit 006ce0b84643f1999004dcef9a0a6a167c16efae
Author: Rob Clark <robin.clark@oss.qualcomm.com>

drm/msm/a6xx: Access VM directly in submit path

This commit changes the a6xx_set_pagetable() function to access the
context VM directly (ctx->vm) instead of calling msm_context_vm(). It
relies on the assumption that the GEM_SUBMIT ioctl has already ensured
the VM is created by the time this code is reached.

> drm/msm/a6xx: Access VM directly in submit path
> 
> The GEM_SUBMIT ioctl has already ensured that the VM is created, so we
> aren't expecting to lazily create the VM this deep into the ioctl.

[Severity: Critical]
This is a pre-existing issue, but does the GEM_SUBMIT ioctl actually ensure
the VM is created?

Looking at msm_ioctl_gem_submit() in drivers/gpu/drm/msm/msm_gem_submit.c,
the early validation path accesses the VM directly without calling
msm_context_vm() to ensure it has been created:

drivers/gpu/drm/msm/msm_gem_submit.c:msm_ioctl_gem_submit() {
    ...
	if (to_msm_vm(ctx->vm)->unusable)
		return UERR(EPIPE, dev, "context is unusable");
    ...
}

Can unprivileged userspace trigger a NULL pointer dereference by calling the
MSM_GEM_SUBMIT ioctl on a fresh DRM device descriptor where the context VM
has not been lazily initialized yet?

> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 8b3bb2fd433ba..7f1673163f671 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -229,7 +229,7 @@ static void a6xx_set_pagetable(struct a6xx_gpu *a6xx_gpu,
>  {
>  	bool sysprof = msm_gpu_sysprof_no_perfcntr_zap(&a6xx_gpu->base.base);
>  	struct msm_context *ctx = submit->queue->ctx;
> -	struct drm_gpuvm *vm = msm_context_vm(submit->dev, ctx);
> +	struct drm_gpuvm *vm = ctx->vm;
>  	struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
>  	phys_addr_t ttbr;
>  	u32 asid;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716201538.365824-1-robin.clark@oss.qualcomm.com?part=4

  reply	other threads:[~2026-07-16 20:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-16 20:15 [PATCH v5 00/10] drm/msm: A couple lazy-vm fixes Rob Clark
2026-07-16 20:15 ` [PATCH v5 01/10] drm/msm: Fix barriers accessing ctx vm Rob Clark
2026-07-16 20:31   ` sashiko-bot
2026-07-16 20:15 ` [PATCH v5 02/10] drm/msm: Rework queuelock Rob Clark
2026-07-16 20:39   ` sashiko-bot
2026-07-16 20:15 ` [PATCH v5 03/10] drm/msm: Synchronize VM creation on ctxlock Rob Clark
2026-07-16 20:33   ` sashiko-bot
2026-07-16 20:15 ` [PATCH v5 04/10] drm/msm/a6xx: Access VM directly in submit path Rob Clark
2026-07-16 20:43   ` sashiko-bot [this message]
2026-07-16 20:15 ` [PATCH v5 05/10] drm/msm: Add helper to check for per-process pgtables VM Rob Clark
2026-07-16 20:15 ` [PATCH v5 06/10] drm/msm: Allow lazy VM creation to fail Rob Clark
2026-07-16 20:33   ` sashiko-bot
2026-07-16 20:15 ` [PATCH v5 07/10] drm/msm: Don't fallback to shared VM for VM_BIND Rob Clark
2026-07-16 20:28   ` sashiko-bot
2026-07-16 20:15 ` [PATCH v5 08/10] drm/msm: Validate lazy VM in GEM_NEW Rob Clark
2026-07-16 20:29   ` sashiko-bot
2026-07-16 20:15 ` [PATCH v5 09/10] drm/msm: Fix per-process-pgtables check Rob Clark
2026-07-16 20:48   ` sashiko-bot
2026-07-16 20:15 ` [PATCH v5 10/10] drm/msm: Remove invalid overflow check Rob Clark
2026-07-16 20:34   ` sashiko-bot

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=20260716204308.425001F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=robin.clark@oss.qualcomm.com \
    --cc=sashiko-reviews@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.