[PATCH v3] drm/i915/gem: Don't use VMA from wrong VM in EXECBUF

[PATCH v3] drm/i915/gem: Don't use VMA from wrong VM in EXECBUF

[Joonas Lahtinen]

Do not pick a VMA with non-matching VM (ppGTT) on quick path
of BO handle lookup for a given EXECBUF call. VMA from wrong VM
could be picked if same BO is repeatedly used in EXECBUF
calls on same context with alternating VMs (ppGTTs). However due
to the introduction of proto-ctx that should not be possible since
d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle
 create parameters (v5)").

Also avoids returning a VMA without increasing the refcount,
which may potentially lead to UAF since f7ce8639f6ff ("drm/i915/gem:
Split the context's obj:vma lut into its own mutex") and until
d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle
 create parameters (v5)").

Sima's analysis:

  This check was added in f7ce8639f6ff ("drm/i915/gem: Split the context's
  obj:vma lut into its own mutex") but without any hint in the commit
  message as to why. In another hunk of that commit there's a hint though in
  __eb_add_lut:

          /* user racing with ctx set-vm */

  This would mean that this bug was introduced in e0695db7298e ("drm/i915:
  Create/destroy VM (ppGTT) for use with contexts"), which allowed to change
  the gem_ctx->vm at runtime, opening up the race that was partially fixed
  in the earlier referenced commit about a year later.

  But it cannot be exploited anymore in anything remotely recent because
  with the introduction of proto-contexts we've made gem_ctx->vm invariant
  again, exactly to preemptively close all these potential issues.
  Specifically d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle
  create parameters (v5)") is the vm specific part of the proto-context
  work.

  Despite that this is impossible to exploit I think it's still good to fix,
  but I think for paranoia's sake we should put a WARN_ON_ONCE(vma->vm !=
  vm) in there, since this really should be impossible.

  I don't think there's a  harm in backporting this though, since there's a
  2 year window between the introduction of the ctx->vm change and it's
  complete fix with the proto-ctx work between 2019 and 2021. It's not
  realistic to backport the latter and this here is trivial in case anyone
  is foolish enough to run such an old kernel.

v3:
- Include Sima's analysis and WARN_ON_ONCE

Fixes: f7ce8639f6ff ("drm/i915/gem: Split the context's obj:vma lut into its own mutex")
References: https://lore.kernel.org/all/20260324151741.29338-1-sosohero200@gmail.com/
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Linus Torvalds <torvalds@linuxfoundation.org>
Cc: Simona Vetter <simona.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tursulin@ursulin.net>
Cc: Andi Shyti <andi.shyti@kernel.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index bd608cea396f..16f7c2fac143 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -895,8 +895,12 @@ static struct i915_vma *eb_lookup_vma(struct i915_execbuffer *eb, u32 handle)
 
 		rcu_read_lock();
 		vma = radix_tree_lookup(&eb->gem_context->handles_vma, handle);
-		if (likely(vma && vma->vm == vm))
+		if (likely(vma && vma->vm == vm)) {
 			vma = i915_vma_tryget(vma);
+		} else {
+			WARN_ON_ONCE(vma && vma->vm != vm);
+			vma = NULL;
+		}
 		rcu_read_unlock();
 		if (likely(vma))
 			return vma;
-- 
2.53.0

Re: [PATCH v3] drm/i915/gem: Don't use VMA from wrong VM in EXECBUF

[Simona Vetter]

On Wed, Apr 08, 2026 at 02:05:51PM +0300, Joonas Lahtinen wrote:
> Do not pick a VMA with non-matching VM (ppGTT) on quick path
> of BO handle lookup for a given EXECBUF call. VMA from wrong VM
> could be picked if same BO is repeatedly used in EXECBUF
> calls on same context with alternating VMs (ppGTTs). However due
> to the introduction of proto-ctx that should not be possible since
> d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle
>  create parameters (v5)").
> 
> Also avoids returning a VMA without increasing the refcount,
> which may potentially lead to UAF since f7ce8639f6ff ("drm/i915/gem:
> Split the context's obj:vma lut into its own mutex") and until
> d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle
>  create parameters (v5)").

Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>

Also, much more succinct summary above than my babbling below :-)

Cheers, Sima

> 
> Sima's analysis:
> 
>   This check was added in f7ce8639f6ff ("drm/i915/gem: Split the context's
>   obj:vma lut into its own mutex") but without any hint in the commit
>   message as to why. In another hunk of that commit there's a hint though in
>   __eb_add_lut:
> 
>           /* user racing with ctx set-vm */
> 
>   This would mean that this bug was introduced in e0695db7298e ("drm/i915:
>   Create/destroy VM (ppGTT) for use with contexts"), which allowed to change
>   the gem_ctx->vm at runtime, opening up the race that was partially fixed
>   in the earlier referenced commit about a year later.
> 
>   But it cannot be exploited anymore in anything remotely recent because
>   with the introduction of proto-contexts we've made gem_ctx->vm invariant
>   again, exactly to preemptively close all these potential issues.
>   Specifically d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle
>   create parameters (v5)") is the vm specific part of the proto-context
>   work.
> 
>   Despite that this is impossible to exploit I think it's still good to fix,
>   but I think for paranoia's sake we should put a WARN_ON_ONCE(vma->vm !=
>   vm) in there, since this really should be impossible.
> 
>   I don't think there's a  harm in backporting this though, since there's a
>   2 year window between the introduction of the ctx->vm change and it's
>   complete fix with the proto-ctx work between 2019 and 2021. It's not
>   realistic to backport the latter and this here is trivial in case anyone
>   is foolish enough to run such an old kernel.
> 
> v3:
> - Include Sima's analysis and WARN_ON_ONCE
> 
> Fixes: f7ce8639f6ff ("drm/i915/gem: Split the context's obj:vma lut into its own mutex")
> References: https://lore.kernel.org/all/20260324151741.29338-1-sosohero200@gmail.com/
> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linuxfoundation.org>
> Cc: Simona Vetter <simona.vetter@ffwll.ch>
> Cc: Tvrtko Ursulin <tursulin@ursulin.net>
> Cc: Andi Shyti <andi.shyti@kernel.org>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index bd608cea396f..16f7c2fac143 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -895,8 +895,12 @@ static struct i915_vma *eb_lookup_vma(struct i915_execbuffer *eb, u32 handle)
>  
>  		rcu_read_lock();
>  		vma = radix_tree_lookup(&eb->gem_context->handles_vma, handle);
> -		if (likely(vma && vma->vm == vm))
> +		if (likely(vma && vma->vm == vm)) {
>  			vma = i915_vma_tryget(vma);
> +		} else {
> +			WARN_ON_ONCE(vma && vma->vm != vm);
> +			vma = NULL;
> +		}
>  		rcu_read_unlock();
>  		if (likely(vma))
>  			return vma;
> -- 
> 2.53.0
> 

-- 
Simona Vetter
Software Engineer
http://blog.ffwll.ch

✗ Fi.CI.BUILD: failure for drm/i915/gem: Don't use VMA from wrong VM in EXECBUF (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Don't use VMA from wrong VM in EXECBUF (rev3)
URL   : https://patchwork.freedesktop.org/series/164504/
State : failure

== Summary ==

Error: patch https://patchwork.freedesktop.org/api/1.0/series/164504/revisions/3/mbox/ not applied
Applying: drm/i915/gem: Don't use VMA from wrong VM in EXECBUF
Using index info to reconstruct a base tree...
M	drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915/gem: Don't use VMA from wrong VM in EXECBUF
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Build failed, no error log produced