public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
From: Claude Code Review Bot <claude-review@example.com>
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:54:46 +1000	[thread overview]
Message-ID: <review-patch1-20260408082859.69823-1-joonas.lahtinen@linux.intel.com> (raw)
In-Reply-To: <20260408082859.69823-1-joonas.lahtinen@linux.intel.com>

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

  parent reply	other threads:[~2026-04-12  2:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-08  8:28 [PATCH] drm/i915/gem: Don't use VMA from wrong VM in EXECBUF Joonas Lahtinen
2026-04-08  8:34 ` Joonas Lahtinen
2026-04-08  9:08 ` Simona Vetter
2026-04-12  2:54 ` Claude review: " Claude Code Review Bot
2026-04-12  2:54 ` Claude Code Review Bot [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-04-08 10:59 [PATCH v2] " Joonas Lahtinen
2026-04-12  2:37 ` Claude review: " Claude Code Review Bot
2026-04-12  2:37 ` Claude Code Review Bot
2026-04-08 11:05 [PATCH v3] " Joonas Lahtinen
2026-04-12  2:35 ` Claude review: " Claude Code Review Bot
2026-04-12  2:35 ` Claude Code Review Bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=review-patch1-20260408082859.69823-1-joonas.lahtinen@linux.intel.com \
    --to=claude-review@example.com \
    --cc=dri-devel-reviews@example.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox