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

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

Overall Series Review

Subject: drm/i915/gem: Don't use VMA from wrong VM in EXECBUF
Author: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Patches: 2
Reviewed: 2026-04-12T12:35:35.504824

---

This is a single-patch fix for a potential use-after-free bug in the i915 EXECBUF VMA lookup fast path. The patch is well-analyzed, with thorough commit message documentation including Sima's historical analysis of the bug's origin, exploitability window, and current status.

**The core bug:** In `eb_lookup_vma()`, when a VMA is found in the radix tree but belongs to the wrong VM (`vma->vm != vm`), the original code fell through without setting `vma = NULL` or acquiring a reference. This left `vma` holding a raw pointer from `radix_tree_lookup()`, which would then be returned to the caller without a refcount via `if (likely(vma)) return vma;` — a potential UAF.

**Note on apply failure:** The patch did not apply cleanly because the current drm-next tree already contains an `else vma = NULL;` branch at this location (lines 901-902), meaning the NULL-assignment part of this fix is already present. The patch is based on an older tree that lacked this `else` branch entirely. What the patch adds beyond the current tree is the `WARN_ON_ONCE` diagnostic.

**Assessment:** The fix is correct and the code change is trivially small. The `WARN_ON_ONCE` is a sensible paranoia check per Sima's suggestion, since proto-contexts should make the condition impossible to trigger on any kernel >= 5.15ish. The Fixes tag correctly points to the commit that introduced the race window. The patch is suitable for stable backport to cover the 2019-2021 window where the bug was exploitable.

---

---
Generated by Claude Code Patch Reviewer