Claude review: drm/i915/gem: Don't use VMA from wrong VM in EXECBUF

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**The bug:** In `eb_lookup_vma()`, the fast-path lookup does:

```c
rcu_read_lock();
vma = radix_tree_lookup(&eb->gem_context->handles_vma, handle);
if (likely(vma && vma->vm == vm))
    vma = i915_vma_tryget(vma);
rcu_read_unlock();
if (likely(vma))
    return vma;
```

When `radix_tree_lookup` succeeds but `vma->vm != vm`, the `if` branch is not taken and `i915_vma_tryget()` is never called. However, `vma` remains non-NULL (still pointing to the result of `radix_tree_lookup`). After `rcu_read_unlock()`, the `if (likely(vma))` check passes and returns this VMA — from the wrong VM, without a reference count increment. After `rcu_read_unlock()`, the VMA could be freed at any time, making this a potential UAF.

**The fix** adds `else vma = NULL;` to reset `vma` when the VM doesn't match:

```c
if (likely(vma && vma->vm == vm))
    vma = i915_vma_tryget(vma);
else
    vma = NULL;
```

This is correct. The `else` branch covers two cases:
1. `vma` was NULL from the radix_tree_lookup (no-op, NULL stays NULL).
2. `vma->vm != vm` (the actual bug — now properly handled by resetting to NULL).

After this fix, when the VM doesn't match, the code falls through to the slow path which calls `i915_gem_object_lookup()` and `i915_vma_instance()` to properly create/find the correct VMA for the right VM.

**Minor observation:** Simona's analysis suggests adding `WARN_ON_ONCE(vma->vm != vm)` for paranoia, since the mismatch should be impossible with proto-contexts. The v2 doesn't include this. This seems like a reasonable choice for a stable-targeted fix — a WARN_ON would be noisy on older kernels where the mismatch was legitimately possible. That said, if this is only going to drm-next, a `WARN_ON_ONCE` after `rcu_read_unlock()` would be a nice debugging aid for catching any future regressions that re-introduce mutable `gem_ctx->vm`. I'd leave this to the maintainer's preference.

**Commit message quality:** Excellent. The Fixes tag, References link, and Simona's detailed analysis provide full historical context and rationale. The message correctly identifies both the wrong-VM and the missing-refcount aspects of the bug.

**Verdict:** Reviewed-by worthy. The fix is minimal, correct, and well-documented.

---
Generated by Claude Code Patch Reviewer