[PATCH] drm/i915: Fix UAF race between relocation and GEM_CLOSE

[PATCH] drm/i915: Fix UAF race between relocation and GEM_CLOSE

[Yassine Mounir]

A use-after-free (UAF) vulnerability was identified in the i915 driver 
within eb_relocate_vma. The issue arises from a race condition where 
a concurrent DRM_IOCTL_GEM_CLOSE can drop the GEM object's reference 
count to zero while the relocation thread is still processing entries.

This results in the kernel attempting to access freed memory in 
eb_relocate_entry, leading to a display pipeline hang and potential 
system instability.

Fix:
Wrap the relocation phase with i915_gem_object_get() and 
i915_gem_object_put() to ensure the object remains valid throughout 
the operation, even if user-space requests to close the handle.

Reported-by: Yassine Mounir (Toji1) <sosohero200@gmail.com>
Signed-off-by: Yassine Mounir <sosohero200@gmail.com>
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1542,7 +1542,11 @@ eb_relocate_vma(struct i915_execbuffer *eb, struct i915_vma *vma)
 		if (ret)
 			return ret;
 
+		/* Hold a reference to prevent UAF during concurrent GEM_CLOSE */
+		i915_gem_object_get(vma->obj);
 		ret = eb_relocate_entry(eb, vma, rel);
+		i915_gem_object_put(vma->obj);
+
 		if (ret)
 			return ret;
 	}

Re: [PATCH] drm/i915: Fix UAF race between relocation and GEM_CLOSE

[Greg KH]

On Tue, Mar 24, 2026 at 09:47:18AM -0400, Yassine Mounir wrote:
> A use-after-free (UAF) vulnerability was identified in the i915 driver 
> within eb_relocate_vma. The issue arises from a race condition where 
> a concurrent DRM_IOCTL_GEM_CLOSE can drop the GEM object's reference 
> count to zero while the relocation thread is still processing entries.
> 
> This results in the kernel attempting to access freed memory in 
> eb_relocate_entry, leading to a display pipeline hang and potential 
> system instability.
> 
> Fix:
> Wrap the relocation phase with i915_gem_object_get() and 
> i915_gem_object_put() to ensure the object remains valid throughout 
> the operation, even if user-space requests to close the handle.
> 
> Reported-by: Yassine Mounir (Toji1) <sosohero200@gmail.com>
> Signed-off-by: Yassine Mounir <sosohero200@gmail.com>

No need for a reported-by when you create and sign off on a change.

> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c

There is no such file name in the current kernel tree, what version did
you make this against?


> @@ -1542,7 +1542,11 @@ eb_relocate_vma(struct i915_execbuffer *eb, struct i915_vma *vma)
>  		if (ret)
>  			return ret;
>  
> +		/* Hold a reference to prevent UAF during concurrent GEM_CLOSE */
> +		i915_gem_object_get(vma->obj);
>  		ret = eb_relocate_entry(eb, vma, rel);
> +		i915_gem_object_put(vma->obj);
> +

What prevents the object from going away right after the put call here?

thanks,

greg k-h

Re: [PATCH] drm/i915: Fix UAF race between relocation and GEM_CLOSE

[Yassine Mounir]

[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]

*Hi Greg,*

*My apologies for the confusion. I realized I was developing against a
distribution kernel (6.18.12-kali). I understand now why the file paths do
not match the current upstream tree.*

*Regarding the logic: The race condition happens specifically during the
eb_relocate_entry call when a concurrent GEM_CLOSE drops the reference
count to zero. The i915_gem_object_get is intended to pin the object's
lifetime during this critical relocation window.*

*I will now rebase this fix against the latest drm-tip / mainline tree,
remove the 'Reported-by' tag as suggested, and submit a v2 for review.*

*Thank you for your guidance.* *Best regards,*

*Yassine (Toji1)*

Le mar. 24 mars 2026 à 10:27, Greg KH <gregkh@linuxfoundation.org> a écrit :

> On Tue, Mar 24, 2026 at 09:47:18AM -0400, Yassine Mounir wrote:
> > A use-after-free (UAF) vulnerability was identified in the i915 driver
> > within eb_relocate_vma. The issue arises from a race condition where
> > a concurrent DRM_IOCTL_GEM_CLOSE can drop the GEM object's reference
> > count to zero while the relocation thread is still processing entries.
> >
> > This results in the kernel attempting to access freed memory in
> > eb_relocate_entry, leading to a display pipeline hang and potential
> > system instability.
> >
> > Fix:
> > Wrap the relocation phase with i915_gem_object_get() and
> > i915_gem_object_put() to ensure the object remains valid throughout
> > the operation, even if user-space requests to close the handle.
> >
> > Reported-by: Yassine Mounir (Toji1) <sosohero200@gmail.com>
> > Signed-off-by: Yassine Mounir <sosohero200@gmail.com>
>
> No need for a reported-by when you create and sign off on a change.
>
> > ---
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>
> There is no such file name in the current kernel tree, what version did
> you make this against?
>
>
> > @@ -1542,7 +1542,11 @@ eb_relocate_vma(struct i915_execbuffer *eb,
> struct i915_vma *vma)
> >               if (ret)
> >                       return ret;
> >
> > +             /* Hold a reference to prevent UAF during concurrent
> GEM_CLOSE */
> > +             i915_gem_object_get(vma->obj);
> >               ret = eb_relocate_entry(eb, vma, rel);
> > +             i915_gem_object_put(vma->obj);
> > +
>
> What prevents the object from going away right after the put call here?
>
> thanks,
>
> greg k-h
>

[-- Attachment #2: Type: text/html, Size: 3426 bytes --]

Re: [PATCH] drm/i915: Fix UAF race between relocation and GEM_CLOSE

[Greg KH]

On Tue, Mar 24, 2026 at 10:38:24AM -0400, Yassine Mounir wrote:
> *Hi Greg,*

Hi, but please do not top-post nor send html email, that gets dropped by
the mailing lists.

> *My apologies for the confusion. I realized I was developing against a
> distribution kernel (6.18.12-kali). I understand now why the file paths do
> not match the current upstream tree.*
> 
> *Regarding the logic: The race condition happens specifically during the
> eb_relocate_entry call when a concurrent GEM_CLOSE drops the reference
> count to zero. The i915_gem_object_get is intended to pin the object's
> lifetime during this critical relocation window.*

But what happens if the object is dropped right after your call to put?
It will now be gone and not be around to work for the rest of the loop.

thnaks,

greg k-h

Re: [PATCH] drm/i915: Fix UAF race between relocation and GEM_CLOSE

[Yassine Mounir]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

On Tue, 24 Mar 2026 at 11:15, Greg KH <gregkh@linuxfoundation.org> wrote:

> On Tue, Mar 24, 2026 at 10:38:24AM -0400, Yassine Mounir wrote:
> > *Hi Greg,*
>
> Hi, but please do not top-post nor send html email, that gets dropped by
> the mailing lists.
>
> > *My apologies for the confusion. I realized I was developing against a
> > distribution kernel (6.18.12-kali). I understand now why the file paths
> do
> > not match the current upstream tree.*
> >
> > *Regarding the logic: The race condition happens specifically during the
> > eb_relocate_entry call when a concurrent GEM_CLOSE drops the reference
> > count to zero. The i915_gem_object_get is intended to pin the object's
> > lifetime during this critical relocation window.*
>
> But what happens if the object is dropped right after your call to put?
> It will now be gone and not be around to work for the rest of the loop.
>
> thnaks,
>
> greg k-h
>


 Hi Greg,

You are absolutely right about v1. I have just submitted v2 which addresses
this concern.

In the new version, I moved i915_gem_object_get() to before the relocation
loop starts and i915_gem_object_put() to the common exit path ('out'
label). This ensures the object's lifetime is guaranteed and pinned
throughout the entire relocation phase, regardless of concurrent GEM_CLOSE
calls.

I also fixed the directory path and removed the Reported-by tag.

Thanks,

Yassine(toji1)

[-- Attachment #2: Type: text/html, Size: 1978 bytes --]

✗ LGCI.VerificationFailed: failure for drm/i915: Fix UAF race between relocation and GEM_CLOSE

[Patchwork]

== Series Details ==

Series: drm/i915: Fix UAF race between relocation and GEM_CLOSE
URL   : https://patchwork.freedesktop.org/series/163842/
State : failure

== Summary ==

Address 'sosohero200@gmail.com' is not on the allowlist, which prevents CI from being triggered for this patch.
If you want Intel GFX CI to accept this address, please contact the script maintainers at i915-ci-infra@lists.freedesktop.org.
Exception occurred during validation, bailing out!