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

[Simona Vetter <simona.vetter@ffwll.ch>]

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