Pin the object lifetime in eb_relocate_vma() using i915_gem_object_get()
and i915_gem_object_put() to prevent a Use-After-Free (UAF) if the
handle is closed concurrently during relocation.

Additionally, simplify eb_lookup_vma() by removing the redundant
vma->vm == vm check. As noted by Joonas, this check is unnecessary since
commit d4433c7600f7. Removing it also avoids the "insane" logic of
returning a VMA without a reference, satisfying the sanity requirements
requested by Linus.

Fixes: d4433c7600f7 ("drm/i915: Multi-vm support")
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Signed-off-by: Yassine Mounir <sosohero200@gmail.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 942f4eed8..50eeb4771 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -896,10 +896,8 @@ 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 = i915_vma_tryget(vma);
-		else
-			vma = NULL;
 		rcu_read_unlock();
 		if (likely(vma))
 			return vma;
@@ -1529,7 +1527,7 @@ static int eb_relocate_vma(struct i915_execbuffer *eb, struct eb_vma *ev)
 	 */
 	if (unlikely(!access_ok(urelocs, remain * sizeof(*urelocs))))
 		return -EFAULT;
-
+	i915_gem_object_get(ev->vma->obj);
 	do {
 		struct drm_i915_gem_relocation_entry *r = stack;
 		unsigned int count =
@@ -1590,6 +1588,7 @@ static int eb_relocate_vma(struct i915_execbuffer *eb, struct eb_vma *ev)
 		urelocs += ARRAY_SIZE(stack);
 	} while (remain);
 out:
+	i915_gem_object_put(ev->vma->obj);
 	reloc_cache_reset(&eb->reloc_cache, eb);
 	return remain;
 }
-- 
2.51.0

Quoting Yassine Mounir (2026-04-09 01:49:05)
> Pin the object lifetime in eb_relocate_vma() using i915_gem_object_get()
> and i915_gem_object_put() to prevent a Use-After-Free (UAF) if the
> handle is closed concurrently during relocation.

This has simply not been a bug that could have happened since drm-tip
2021. The vma refcount is taken in the eb_lookup_vma and it is very
thoroughly explained in [1] when the refcount could be missed
historically.

Either this is a pure AI hallucination or you've been running
some older downstream kernel with drm from 2020-2021 without the
proto-ctx changes.

Assessing that is impossible for now as you failed to supply any
relevant dmesg against drm-tip on real hardware or any other proof
about a claimed crash. Log of serial QEMU session where the relevant
driver is not even loaded is not helping.

If you want to continue the discussion here, provide a non AI
generated KASAN splat against drm-tip kernel which you promised multiple
messages ago.

To address a bug in downstream kernel, you should either update your
distro and/or ask the downstream kernel provider to supply a more
up-to-date kernel.

Regards, Joonas

[1] https://lore.kernel.org/intel-gfx/20260409053111.8914-1-joonas.lahtinen@linux.intel.com/