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

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

[Joonas Lahtinen]

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)").

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

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

[Simona Vetter]

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

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

[Claude Code Review Bot]

Patch Review

**Correctness: Good.** The logic change is sound:

```c
-		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;
+		}
```

The `else` branch is entered when `!(vma && vma->vm == vm)`, which covers two cases:
1. `vma == NULL` — no entry in radix tree (benign, `WARN_ON_ONCE` condition is false)
2. `vma != NULL && vma->vm != vm` — wrong VM (the bug, `WARN_ON_ONCE` fires)

Both cases correctly set `vma = NULL`, preventing the un-refcounted pointer from being returned at line 904's `if (likely(vma)) return vma;`.

**RCU safety:** The `vma->vm` dereference in the `WARN_ON_ONCE` is safe because we're still inside `rcu_read_lock()`, so the VMA can't be freed underneath us.

**Minor observations:**

1. **Conflict with current tree:** As noted, the drm-next tree already has `else vma = NULL;` at this location. The patch will need a trivial rebase to apply on top of that — essentially just adding the `WARN_ON_ONCE` inside the existing `else` branch. It would be worth confirming who already applied the partial fix and whether that commit should be referenced.

2. **WARN_ON_ONCE appropriateness:** Given Sima's analysis that this condition is impossible to trigger on any kernel with proto-contexts (>= d4433c7600f7), `WARN_ON_ONCE` is the right severity — it shouldn't fire in practice, but if it ever does, it signals a serious regression in the VM invariant. A `drm_WARN_ON_ONCE` passing the `i915` device might be slightly preferred for consistency with the rest of the i915 driver's warning style, but this is a very minor nit.

3. **Commit message quality:** Excellent. The historical analysis, the Fixes tag, the References link to the original report, and the explanation of why it's safe to backport are all thorough and helpful for anyone reading this in `git log` later.

**Verdict:** The patch is correct and ready to merge, pending a trivial rebase against the current tree. Consider using `drm_WARN_ON_ONCE()` instead of `WARN_ON_ONCE()` for i915 driver convention consistency.

---
Generated by Claude Code Patch Reviewer

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

[Claude Code Review Bot]

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

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

[Joonas Lahtinen]

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)").

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.

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 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index bd608cea396f..7463c3262651 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -897,6 +897,8 @@ static struct i915_vma *eb_lookup_vma(struct i915_execbuffer *eb, u32 handle)
 		vma = radix_tree_lookup(&eb->gem_context->handles_vma, handle);
 		if (likely(vma && vma->vm == vm))
 			vma = i915_vma_tryget(vma);
+		else
+			vma = NULL;
 		rcu_read_unlock();
 		if (likely(vma))
 			return vma;
-- 
2.53.0

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

[Claude Code Review Bot]

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: 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_tryget()` 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 — both a correctness bug and a potential use-after-free.

As the commit message thoroughly explains (with Simona's analysis), this race window was introduced by the runtime VM-change feature in 2019 and was effectively closed in 2021 by making `gem_ctx->vm` invariant via proto-contexts. So the bug is not exploitable on any remotely modern kernel, but the fix 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 objections to merging.**

---
Generated by Claude Code Patch Reviewer

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

[Claude Code Review Bot]

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

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

[Joonas Lahtinen]

Do not pick 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).

Also avoids returning a VMA without increasing the refcount,
which may potentially lead to UAF.

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>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index bd608cea396f..7463c3262651 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -897,6 +897,8 @@ static struct i915_vma *eb_lookup_vma(struct i915_execbuffer *eb, u32 handle)
 		vma = radix_tree_lookup(&eb->gem_context->handles_vma, handle);
 		if (likely(vma && vma->vm == vm))
 			vma = i915_vma_tryget(vma);
+		else
+			vma = NULL;
 		rcu_read_unlock();
 		if (likely(vma))
 			return vma;
-- 
2.53.0

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

[Claude Code Review Bot]

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: 3
Reviewed: 2026-04-12T12:54:46.193333

---

This is a single, well-targeted bug fix for a real correctness and potential use-after-free issue in the i915 GEM execbuffer VMA lookup fast path. The fix is minimal (2 lines), correct, and addresses a clear logic gap. The drm-next tree already carries this fix, confirming it has been accepted.

**Verdict: Good patch, should be applied.**

---
Generated by Claude Code Patch Reviewer

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

[Claude Code Review Bot]

Patch Review

**The Bug:**

In `eb_lookup_vma()`, the fast path does a radix tree lookup and then checks if the VMA belongs to the correct VM (ppGTT):

```c
vma = radix_tree_lookup(&eb->gem_context->handles_vma, handle);
if (likely(vma && vma->vm == vm))
    vma = i915_vma_tryget(vma);
// BUG: if the condition is false, vma still holds the stale pointer
rcu_read_unlock();
if (likely(vma))
    return vma;  // returns VMA from wrong VM, without refcount!
```

Without the `else vma = NULL;`, when a VMA is found in the radix tree but belongs to a **different** VM (`vma->vm != vm`), the code falls through with `vma` still pointing to the looked-up (wrong-VM) VMA. The subsequent `if (likely(vma))` check sees a non-NULL pointer and **returns it**.

This causes two distinct problems:

1. **Wrong VM VMA returned**: The caller gets a VMA bound to a different address space than intended. If the same BO is used across EXECBUF calls with alternating VMs on the same context, the wrong VMA could be selected, leading to incorrect GPU address translations.

2. **Missing refcount (potential UAF)**: `i915_vma_tryget()` is only called when the VM matches, so the returned VMA has no reference taken on it. Once the RCU read lock is released, nothing prevents the VMA from being freed, creating a use-after-free condition.

**The Fix:**

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

Setting `vma = NULL` on the else branch ensures the fast path is skipped when the VM doesn't match, correctly falling through to the slow path which calls `i915_vma_instance(obj, vm, NULL)` to find or create the proper VMA for the correct VM, with proper refcounting.

**Assessment**: The fix is correct and minimal. The `else` branch also covers the case where `vma` was NULL from the radix tree lookup (a no-op assignment but harmless). The patch is well-described, references the original report, and has appropriate tags. No concerns.

---
Generated by Claude Code Patch Reviewer