public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Simona Vetter <simona.vetter@ffwll.ch>
To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: "Intel graphics driver community testing & development"
	<intel-gfx@lists.freedesktop.org>,
	"Direct Rendering Infrastructure - Development"
	<dri-devel@lists.freedesktop.org>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Linus Torvalds" <torvalds@linuxfoundation.org>
Subject: Re: [PATCH] drm/i915/gem: Don't use VMA from wrong VM in EXECBUF
Date: Wed, 8 Apr 2026 11:08:06 +0200	[thread overview]
Message-ID: <adYa9rf5fgL8-DVq@phenom.ffwll.local> (raw)
In-Reply-To: <20260408082859.69823-1-joonas.lahtinen@linux.intel.com>

On Wed, Apr 08, 2026 at 11:28:59AM +0300, Joonas Lahtinen wrote:
> 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))

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.

With the WARN_ON_ONCE added and the above analysis included this is

Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>

Cheers, Sima

PS: Caught a cold, brain's not entirely working, this might be all very
wrong so please check my history digging.

>  			vma = i915_vma_tryget(vma);
> +		else
> +			vma = NULL;
>  		rcu_read_unlock();
>  		if (likely(vma))
>  			return vma;
> -- 
> 2.53.0
> 

-- 
Simona Vetter
Software Engineer
http://blog.ffwll.ch

      parent reply	other threads:[~2026-04-08  9:08 UTC|newest]

Thread overview: 3+ 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 [this message]

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=adYa9rf5fgL8-DVq@phenom.ffwll.local \
    --to=simona.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=torvalds@linuxfoundation.org \
    --cc=ville.syrjala@linux.intel.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