From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/i915/gem: Don't use VMA from wrong VM in EXECBUF Date: Sun, 12 Apr 2026 12:37:22 +1000 Message-ID: In-Reply-To: <20260408105932.82810-1-joonas.lahtinen@linux.intel.com> References: <20260408105932.82810-1-joonas.lahtinen@linux.intel.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: drm/i915/gem: Don't use VMA from wrong VM in EXECBUF Author: Joonas Lahtinen Patches: 1 Reviewed: 2026-04-12T12:37:22.647331 --- This is a single-patch fix for a bug in the i915 GEM execbuffer VMA lookup = fast path. The issue is straightforward: when `radix_tree_lookup` returns a= VMA that belongs to a different VM (ppGTT), the code skips the `i915_vma_t= ryget()` reference acquisition but still falls through with a non-NULL `vma= ` pointer. This results in returning a VMA from the wrong VM **without** a = reference =E2=80=94 both a correctness bug and a potential use-after-free. As the commit message thoroughly explains (with Simona's analysis), this ra= ce window was introduced by the runtime VM-change feature in 2019 and was e= ffectively closed in 2021 by making `gem_ctx->vm` invariant via proto-conte= xts. So the bug is not exploitable on any remotely modern kernel, but the f= ix is still the right thing to do for code hygiene and for stable backports= to older kernels where the window was open. The fix is minimal, correct, and appropriate for stable backport. **No obje= ctions to merging.** --- Generated by Claude Code Patch Reviewer