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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox