Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Yassine Mounir <sosohero200@gmail.com>, g@freedesktop.org
Cc: gregkh@linuxfoundation.org, intel-gfx@lists.freedesktop.org,
	joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com,
	security@kernel.org
Subject: Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma
Date: Thu, 26 Mar 2026 14:32:02 +0200	[thread overview]
Message-ID: <acUnQkniqECI0QVY@intel.com> (raw)
In-Reply-To: <20260324151741.29338-1-sosohero200@gmail.com>

On Tue, Mar 24, 2026 at 11:17:41AM -0400, Yassine Mounir wrote:
> Fix a race condition in Linux 7.0-rc2 where a GEM object could be freed
> during relocation if userspace closes the handle concurrently.
> 
> The fix involves pinning the object lifetime using i915_gem_object_get()
> before the relocation loop and releasing it via i915_gem_object_put()
> in the common exit path (out label), ensuring symmetry in both success
> and error paths.
> 
> This v2 rebases the change to the new 'gem/' directory structure in
> the current mainline tree and addresses potential memory leaks in
> early error returns.
> 
> Signed-off-by: Yassine Mounir <sosohero200@gmail.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 e7918f896..0468c0551 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1528,6 +1528,7 @@ static int eb_relocate_vma(struct i915_execbuffer *eb, struct eb_vma *ev)
>  	if (unlikely(!access_ok(urelocs, remain * sizeof(*urelocs))))
>  		return -EFAULT;
>  
> +	i915_gem_object_get(ev->vma->obj);
>  	do {
>  		struct drm_i915_gem_relocation_entry *r = stack;
>  		unsigned int count =
> @@ -1588,6 +1589,7 @@ static int eb_relocate_vma(struct i915_execbuffer *eb, struct eb_vma *ev)
>  		urelocs += ARRAY_SIZE(stack);
>  	} while (remain);
>  out:
> +	i915_gem_object_put(ev->vma->obj);
>  	reloc_cache_reset(&eb->reloc_cache, eb);
>  	return remain;


Ignoring the AI slop aspect, I did have a quick look at the code a bit
and noticed this:

eb_lookup_vma() {
	...
	rcu_read_lock();
	vma = radix_tree_lookup(...);
	if (likely(vma && vma->vm == vm))
		vma = i915_vma_tryget(vma);
	rcu_read_unlock();
	if (likely(vma))
		return vma;
	...
}

So if we somehow get a vma with the wrong vm there then we
return the vma without grabbing a reference to it.


Should we not do something like this?

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

-- 
Ville Syrjälä
Intel

  parent reply	other threads:[~2026-03-26 12:32 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24 15:17 [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma Yassine Mounir
2026-03-25  8:01 ` Joonas Lahtinen
2026-03-25  8:20   ` Yassine Mounir
2026-03-25 14:07     ` Joonas Lahtinen
2026-03-25 15:43       ` Yassine Mounir
2026-03-25 15:46       ` Rodrigo Vivi
2026-03-25 17:30         ` Yassine Mounir
2026-03-25 17:30           ` Yassine Mounir
2026-03-25 22:14             ` Rodrigo Vivi
2026-03-25 22:37               ` Yassine Mounir
2026-03-26  6:54                 ` AI slop security report against i915 (Was: Re: [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma) Joonas Lahtinen
2026-03-26  8:45                   ` Greg KH
2026-03-25 15:34 ` ✗ LGCI.VerificationFailed: failure for drm/i915/gem: Fix UAF race in eb_relocate_vma Patchwork
2026-03-26 12:32 ` Ville Syrjälä [this message]
2026-03-26 15:19   ` [PATCH v2] [PATCH v2] " Linus Torvalds
2026-04-03 22:12   ` Linus Torvalds
2026-04-03 22:35     ` Yassine Mounir
2026-04-03 22:38     ` Yassine Mounir
2026-04-07 16:38     ` Joonas Lahtinen
2026-04-07 16:46       ` Linus Torvalds
2026-04-08 11:15         ` Joonas Lahtinen
2026-04-08 15:38           ` Linus Torvalds
2026-04-08 16:24             ` Joonas Lahtinen
2026-04-09 15:45               ` Linus Torvalds
2026-04-13  4:39                 ` Joonas Lahtinen
2026-04-09  8:05         ` Matthew Brost
2026-04-09 15:50           ` Linus Torvalds
2026-04-07 16:58       ` Simona Vetter

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=acUnQkniqECI0QVY@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=g@freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=security@kernel.org \
    --cc=sosohero200@gmail.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