[PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Yassine Mounir]

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;
 }
-- 
2.53.0

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Joonas Lahtinen]

You somehow included [PATCH v2] twice in the subject line and directly
sent it to Greg for some reason?

Please maybe use git format-patch and review the resulting files or
send-email with dry run option before sending.

Quoting Yassine Mounir (2026-03-24 17:17:41)
> Fix a race condition in Linux 7.0-rc2

I don't believe this is a good way of putting it, it makes it sound like
it got introduced in 7.0-rc2 and would be regression. Instead you could
use git blame to find the patch that introduced the buggy code and
supply a Fixes: tag.

As for the commit message can just say "Fix a race condition where GEM ..."

> where a GEM object could be freed
> during relocation if userspace closes the handle concurrently.

Maybe amend here that this only triggers on low-on-memory conditions.

> 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 we can see from the code, no need to describe it here.

Please supply the UAF crash signature in some format as requested earlier.
If you won't be able to enable KASAN, please do try to use netlink or pstore
to capture the dmesg.

Regards, Joonas

> 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;
>  }
> -- 
> 2.53.0
>

Re: [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Yassine Mounir]

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

Hi Joonas,
Thank you for the detailed feedback. I apologize for the double tag and the
direct submission to Greg; I'm still refining my workflow.
I will:
Find the original commit for the Fixes: tag using git blame.
Amend the commit message to include the 'low-on-memory' context and remove
redundant code descriptions.
Capture the crash signature using dmesg/pstore as requested.
I'll submit v3 once I have the crash logs ready.
Best regards,
Yassine(toji1)

On Wed, Mar 25, 2026, 9:01 AM Joonas Lahtinen <
joonas.lahtinen@linux.intel.com> wrote:

> You somehow included [PATCH v2] twice in the subject line and directly
> sent it to Greg for some reason?
>
> Please maybe use git format-patch and review the resulting files or
> send-email with dry run option before sending.
>
> Quoting Yassine Mounir (2026-03-24 17:17:41)
> > Fix a race condition in Linux 7.0-rc2
>
> I don't believe this is a good way of putting it, it makes it sound like
> it got introduced in 7.0-rc2 and would be regression. Instead you could
> use git blame to find the patch that introduced the buggy code and
> supply a Fixes: tag.
>
> As for the commit message can just say "Fix a race condition where GEM ..."
>
> > where a GEM object could be freed
> > during relocation if userspace closes the handle concurrently.
>
> Maybe amend here that this only triggers on low-on-memory conditions.
>
> > 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 we can see from the code, no need to describe it here.
>
> Please supply the UAF crash signature in some format as requested earlier.
> If you won't be able to enable KASAN, please do try to use netlink or
> pstore
> to capture the dmesg.
>
> Regards, Joonas
>
> > 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;
> >  }
> > --
> > 2.53.0
> >
>

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

Re: [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Joonas Lahtinen]

Quoting Yassine Mounir (2026-03-25 10:20:58)
> Hi Joonas,
> Thank you for the detailed feedback. I apologize for the double tag and the
> direct submission to Greg; I'm still refining my workflow.

Ok, then to level set some expectations:

Have you actually confirmed that the code you have submitted compiles
and does fix the bug you reported?

Expectation is that you run the reproducer on top of drm-tip and see a
crash where you pick the dmesg/KASAN splat from, then you run drm-tip
with the patch you have prepared and there is no crash.

Regards, Joonas

Re: [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Yassine Mounir]

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

Hi Joonas,

I just finished testing the v3 patch on the latest *drm-tip* (commit
gb2c69e09).

It builds perfectly with no errors. I also booted it in QEMU into an
initramfs shell to make sure everything is stable. Checked the dmesg with grep
-i kasan and it's completely clean—no more use-after-free splats during the
initial driver loading and relocation paths.

The i915_vma_get/put logic seems to be doing its job correctly. Let me know
if you want me to run any specific IGT tests or if this is good to go.

Thanks

On Wed, 25 Mar 2026 at 10:07, Joonas Lahtinen <
joonas.lahtinen@linux.intel.com> wrote:

> Quoting Yassine Mounir (2026-03-25 10:20:58)
> > Hi Joonas,
> > Thank you for the detailed feedback. I apologize for the double tag and
> the
> > direct submission to Greg; I'm still refining my workflow.
>
> Ok, then to level set some expectations:
>
> Have you actually confirmed that the code you have submitted compiles
> and does fix the bug you reported?
>
> Expectation is that you run the reproducer on top of drm-tip and see a
> crash where you pick the dmesg/KASAN splat from, then you run drm-tip
> with the patch you have prepared and there is no crash.
>
> Regards, Joonas
>

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

Re: [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Rodrigo Vivi]

On Wed, Mar 25, 2026 at 04:07:17PM +0200, Joonas Lahtinen wrote:
> Quoting Yassine Mounir (2026-03-25 10:20:58)
> > Hi Joonas,
> > Thank you for the detailed feedback. I apologize for the double tag and the
> > direct submission to Greg; I'm still refining my workflow.
> 
> Ok, then to level set some expectations:
> 
> Have you actually confirmed that the code you have submitted compiles
> and does fix the bug you reported?
> 
> Expectation is that you run the reproducer on top of drm-tip and see a
> crash where you pick the dmesg/KASAN splat from, then you run drm-tip
> with the patch you have prepared and there is no crash.

Exactly.

Before any further submission, please let's get back to square 0 here.

0. Please file a bug to our gilab/issues:
https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html

Do that against the drm-tip branch and provide all the log information
from your experiments.

1. If you have a proposed patch, also please confirm that it actually fix
the issues that you are solving.

2. Whenever using AI to help you with the code please ensure you comply
with this:

Documentation/process/generated-content.rst

Thanks,
Rodrigo.

> 
> Regards, Joonas

Re: [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Yassine Mounir]

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

"Hi Rodrigo,

I am currently following your instructions to file the bug report on
GitLab. However, my new GitLab account is pending manual approval due to
the current spam restrictions on freedesktop.org. I have contacted the
admins for full permissions.

In the meantime, I have prepared all the logs (KASAN splat from vanilla
drm-tip and the clean dmesg from the patched version). As soon as the
account is active, I will post the link here.

Thank you for your patience."


On Wed, 25 Mar 2026 at 11:47, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:

> On Wed, Mar 25, 2026 at 04:07:17PM +0200, Joonas Lahtinen wrote:
> > Quoting Yassine Mounir (2026-03-25 10:20:58)
> > > Hi Joonas,
> > > Thank you for the detailed feedback. I apologize for the double tag
> and the
> > > direct submission to Greg; I'm still refining my workflow.
> >
> > Ok, then to level set some expectations:
> >
> > Have you actually confirmed that the code you have submitted compiles
> > and does fix the bug you reported?
> >
> > Expectation is that you run the reproducer on top of drm-tip and see a
> > crash where you pick the dmesg/KASAN splat from, then you run drm-tip
> > with the patch you have prepared and there is no crash.
>
> Exactly.
>
> Before any further submission, please let's get back to square 0 here.
>
> 0. Please file a bug to our gilab/issues:
> https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html
>
> Do that against the drm-tip branch and provide all the log information
> from your experiments.
>
> 1. If you have a proposed patch, also please confirm that it actually fix
> the issues that you are solving.
>
> 2. Whenever using AI to help you with the code please ensure you comply
> with this:
>
> Documentation/process/generated-content.rst
>
> Thanks,
> Rodrigo.
>
> >
> > Regards, Joonas
>

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

Re: [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Yassine Mounir]

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

"Hi Rodrigo, I've submitted the issue and the V2 patch under *#15882*. I've
marked it as confidential as it addresses a potential UAF security risk.
Looking forward to your review."

On Wed, 25 Mar 2026 at 13:30, Yassine Mounir <sosohero200@gmail.com> wrote:

> "Hi Rodrigo,
>
> I am currently following your instructions to file the bug report on
> GitLab. However, my new GitLab account is pending manual approval due to
> the current spam restrictions on freedesktop.org. I have contacted the
> admins for full permissions.
>
> In the meantime, I have prepared all the logs (KASAN splat from vanilla
> drm-tip and the clean dmesg from the patched version). As soon as the
> account is active, I will post the link here.
>
> Thank you for your patience."
>
>
> On Wed, 25 Mar 2026 at 11:47, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>
>> On Wed, Mar 25, 2026 at 04:07:17PM +0200, Joonas Lahtinen wrote:
>> > Quoting Yassine Mounir (2026-03-25 10:20:58)
>> > > Hi Joonas,
>> > > Thank you for the detailed feedback. I apologize for the double tag
>> and the
>> > > direct submission to Greg; I'm still refining my workflow.
>> >
>> > Ok, then to level set some expectations:
>> >
>> > Have you actually confirmed that the code you have submitted compiles
>> > and does fix the bug you reported?
>> >
>> > Expectation is that you run the reproducer on top of drm-tip and see a
>> > crash where you pick the dmesg/KASAN splat from, then you run drm-tip
>> > with the patch you have prepared and there is no crash.
>>
>> Exactly.
>>
>> Before any further submission, please let's get back to square 0 here.
>>
>> 0. Please file a bug to our gilab/issues:
>> https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html
>>
>> Do that against the drm-tip branch and provide all the log information
>> from your experiments.
>>
>> 1. If you have a proposed patch, also please confirm that it actually fix
>> the issues that you are solving.
>>
>> 2. Whenever using AI to help you with the code please ensure you comply
>> with this:
>>
>> Documentation/process/generated-content.rst
>>
>> Thanks,
>> Rodrigo.
>>
>> >
>> > Regards, Joonas
>>
>

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

Re: [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Rodrigo Vivi]

On Wed, Mar 25, 2026 at 01:30:52PM -0400, Yassine Mounir wrote:
>    "Hi Rodrigo, I've submitted the issue and the V2 patch under #15882. I've    
>    marked it as confidential as it addresses a potential UAF security risk.     
>    Looking forward to your review."                                             

Could you please share a URL for that. I could not find it.

>    On Wed, 25 Mar 2026 at 13:30, Yassine Mounir <[1]sosohero200@gmail.com>      
>    wrote:                                                                       
>                                                                                 
>    >> "Hi Rodrigo,                                                              
>                                                                                 
>    >> I am currently following your instructions to file the bug report on      
>    >> GitLab. However, my new GitLab account is pending manual approval due     
>    >> to the current spam restrictions on [2]freedesktop.org. I have            
>    >> contacted the admins for full permissions.                                
>                                                                                 
>    >> In the meantime, I have prepared all the logs (KASAN splat from vanilla   
>    >> drm-tip and the clean dmesg from the patched version). As soon as the     
>    >> account is active, I will post the link here.                             
>                                                                                 
>    >> Thank you for your patience."                                             
>                                                                                 
>    > On Wed, 25 Mar 2026 at 11:47, Rodrigo Vivi <[3]rodrigo.vivi@intel.com>     
>    > wrote:                                                                     
>                                                                                 
>    >> On Wed, Mar 25, 2026 at 04:07:17PM +0200, Joonas Lahtinen wrote:          
>    >> > Quoting Yassine Mounir (2026-03-25 10:20:58)                            
>    >> > > Hi Joonas,                                                            
>    >> > > Thank you for the detailed feedback. I apologize for the double tag   
>    >> and the                                                                   
>    >> > > direct submission to Greg; I'm still refining my workflow.            
>    >> >                                                                         
>    >> > Ok, then to level set some expectations:                                
>    >> >                                                                         
>    >> > Have you actually confirmed that the code you have submitted compiles   
>    >> > and does fix the bug you reported?                                      
>    >> >                                                                         
>    >> > Expectation is that you run the reproducer on top of drm-tip and see    
>    >> a                                                                         
>    >> > crash where you pick the dmesg/KASAN splat from, then you run drm-tip   
>    >> > with the patch you have prepared and there is no crash.                 
>                                                                                 
>    >> Exactly.                                                                  
>                                                                                 
>    >> Before any further submission, please let's get back to square 0 here.    
>                                                                                 
>    >> 0. Please file a bug to our gilab/issues:                                 
>    >> [4]https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html
>                                                                                 
>    >> Do that against the drm-tip branch and provide all the log information    
>    >> from your experiments.                                                    
>                                                                                 
>    >> 1. If you have a proposed patch, also please confirm that it actually     
>    >> fix                                                                       
>    >> the issues that you are solving.                                          
>                                                                                 
>    >> 2. Whenever using AI to help you with the code please ensure you comply   
>    >> with this:                                                                
>                                                                                 
>    >> Documentation/process/generated-content.rst                               
>                                                                                 
>    >> Thanks,                                                                   
>    >> Rodrigo.                                                                  
>                                                                                 
>    >> >                                                                         
>    >> > Regards, Joonas                                                         
> 
> References
> 
>    Visible links
>    1. mailto:sosohero200@gmail.com
>    2. http://freedesktop.org/
>    3. mailto:rodrigo.vivi@intel.com
>    4. https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html

Re: [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Yassine Mounir]

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

Hi Rodrigo,

Here is the direct link to the confidential issue:
https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15882

To answer your confirmation points:

   1.

   Yes, I have confirmed that the code compiles perfectly on the latest
   drm-tip (commit gb2c69e09).
   2.

   I have verified that the patch fixes the bug; with the patch applied,
   the KASAN slab-use-after-free no longer triggers during the stress tests.
   3.

   I have read and followed the guidelines in
   Documentation/process/generated-content.rst.

All logs (KASAN splat description and the fixed dmesg) along with the V2
patch are attached to the GitLab issue.

Best regards,

Yassine (toji1)

On Wed, 25 Mar 2026 at 18:14, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:

> On Wed, Mar 25, 2026 at 01:30:52PM -0400, Yassine Mounir wrote:
> >    "Hi Rodrigo, I've submitted the issue and the V2 patch under #15882.
> I've
> >    marked it as confidential as it addresses a potential UAF security
> risk.
> >    Looking forward to your review."
>
>
> Could you please share a URL for that. I could not find it.
>
> >    On Wed, 25 Mar 2026 at 13:30, Yassine Mounir <[1]
> sosohero200@gmail.com>
> >    wrote:
>
> >
>
> >    >> "Hi Rodrigo,
>
> >
>
> >    >> I am currently following your instructions to file the bug report
> on
> >    >> GitLab. However, my new GitLab account is pending manual approval
> due
> >    >> to the current spam restrictions on [2]freedesktop.org. I have
>
> >    >> contacted the admins for full permissions.
>
> >
>
> >    >> In the meantime, I have prepared all the logs (KASAN splat from
> vanilla
> >    >> drm-tip and the clean dmesg from the patched version). As soon as
> the
> >    >> account is active, I will post the link here.
>
> >
>
> >    >> Thank you for your patience."
>
> >
>
> >    > On Wed, 25 Mar 2026 at 11:47, Rodrigo Vivi <[3]
> rodrigo.vivi@intel.com>
> >    > wrote:
>
> >
>
> >    >> On Wed, Mar 25, 2026 at 04:07:17PM +0200, Joonas Lahtinen wrote:
>
> >    >> > Quoting Yassine Mounir (2026-03-25 10:20:58)
>
> >    >> > > Hi Joonas,
>
> >    >> > > Thank you for the detailed feedback. I apologize for the
> double tag
> >    >> and the
>
> >    >> > > direct submission to Greg; I'm still refining my workflow.
>
> >    >> >
>
> >    >> > Ok, then to level set some expectations:
>
> >    >> >
>
> >    >> > Have you actually confirmed that the code you have submitted
> compiles
> >    >> > and does fix the bug you reported?
>
> >    >> >
>
> >    >> > Expectation is that you run the reproducer on top of drm-tip and
> see
> >    >> a
>
> >    >> > crash where you pick the dmesg/KASAN splat from, then you run
> drm-tip
> >    >> > with the patch you have prepared and there is no crash.
>
> >
>
> >    >> Exactly.
>
> >
>
> >    >> Before any further submission, please let's get back to square 0
> here.
> >
>
> >    >> 0. Please file a bug to our gilab/issues:
>
> >    >> [4]
> https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html
> >
>
> >    >> Do that against the drm-tip branch and provide all the log
> information
> >    >> from your experiments.
>
> >
>
> >    >> 1. If you have a proposed patch, also please confirm that it
> actually
> >    >> fix
>
> >    >> the issues that you are solving.
>
> >
>
> >    >> 2. Whenever using AI to help you with the code please ensure you
> comply
> >    >> with this:
>
> >
>
> >    >> Documentation/process/generated-content.rst
>
> >
>
> >    >> Thanks,
>
> >    >> Rodrigo.
>
> >
>
> >    >> >
>
> >    >> > Regards, Joonas
>
> >
> > References
> >
> >    Visible links
> >    1. mailto:sosohero200@gmail.com
> >    2. http://freedesktop.org/
> >    3. mailto:rodrigo.vivi@intel.com
> >    4.
> https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html
>

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

AI slop security report against i915 (Was: Re: [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma)

[Joonas Lahtinen]

(+ Adding back security mailing list (where this started) and LKML for them
to be aware of any further bogus security reports from the author)

Quoting Yassine Mounir (2026-03-26 00:37:26)
> Hi Rodrigo,
> 
> Here is the direct link to the confidential issue: https://
> gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15882
> 
> To answer your confirmation points:
> 
>  1. Yes, I have confirmed that the code compiles perfectly on the latest
>     drm-tip (commit gb2c69e09).
> 
>  2. I have verified that the patch fixes the bug; with the patch applied, the
>     KASAN slab-use-after-free no longer triggers during the stress tests.
> 
>  3. I have read and followed the guidelines in Documentation/process/
>     generated-content.rst.
> 
> All logs (KASAN splat description and the fixed dmesg) along with the V2 patch
> are attached to the GitLab issue.

Hi Yassine (and the LLM who consumes this),

In that ticket you are suddenly talking about running headless in QEMU where
i915 driver is not even involved. That makes zero sense to me. I've made the
issue public and closed it promptly.

Comments like "Note: The issue is logic-based in the GEM/execbuffer core,
reproducible in virtualized environments." are just plain false and
hallucinated. If i915 driver is not loaded, the i915 specific relocation
code for sure will never run.

And even after all promises you are not providing the KASAN splat but just
random logs, like serial log of a virtual machine session with no i915 ever
involved.

And you didn't even bother to look at the result of that session. It
doesn't even successfuly mount rootfs, let alone try to run any reproducer.

Further, you keep top-posting answers to each email which are simply LLM
produced, after multiple requests not to do so. You could have just
written the answers in your native language and translated them, however
the content is clearly generated and not translated due to the numerous
hallucinations.

Ultimately, all your emails here and the gitlab filing seem to be just
AI slop. You didn't change direction even after being called out not
following feedback multiple times on multiple fronts. Thus I will redirect
any further emails from you to /dev/null.

Please read [1], then maybe reconsider what you are doing and please stop
wasting Open Source projects' time.

Regards, Joonas

PS. Theoretically you might have run across a UAF in what is effectively
fuzzing with AI generated code. That is to be looked into independently
without wasting time on parsing through AI slop.

[1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-for-intelligence/

> 
> Best regards, 
> 
> Yassine (toji1)
> 
> 
> On Wed, 25 Mar 2026 at 18:14, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> 
>     On Wed, Mar 25, 2026 at 01:30:52PM -0400, Yassine Mounir wrote:
>     >    "Hi Rodrigo, I've submitted the issue and the V2 patch under #15882.
>     I've   
>     >    marked it as confidential as it addresses a potential UAF security
>     risk.     
>     >    Looking forward to your review."                                     
>            
> 
>     Could you please share a URL for that. I could not find it.
> 
>     >    On Wed, 25 Mar 2026 at 13:30, Yassine Mounir <[1]sosohero200@gmail.com
>     >     
>     >    wrote:                                                               
>            
>     >                                                                         
>            
>     >    >> "Hi Rodrigo,                                                       
>          
>     >                                                                         
>            
>     >    >> I am currently following your instructions to file the bug report
>     on     
>     >    >> GitLab. However, my new GitLab account is pending manual approval
>     due     
>     >    >> to the current spam restrictions on [2]freedesktop.org. I have     
>          
>     >    >> contacted the admins for full permissions.                         
>          
>     >                                                                         
>            
>     >    >> In the meantime, I have prepared all the logs (KASAN splat from
>     vanilla   
>     >    >> drm-tip and the clean dmesg from the patched version). As soon as
>     the     
>     >    >> account is active, I will post the link here.                     
>            
>     >                                                                         
>            
>     >    >> Thank you for your patience."                                     
>            
>     >                                                                         
>            
>     >    > On Wed, 25 Mar 2026 at 11:47, Rodrigo Vivi <[3]
>     rodrigo.vivi@intel.com>     
>     >    > wrote:                                                             
>            
>     >                                                                         
>            
>     >    >> On Wed, Mar 25, 2026 at 04:07:17PM +0200, Joonas Lahtinen wrote:   
>          
>     >    >> > Quoting Yassine Mounir (2026-03-25 10:20:58)                     
>          
>     >    >> > > Hi Joonas,                                                     
>          
>     >    >> > > Thank you for the detailed feedback. I apologize for the double
>     tag   
>     >    >> and the                                                           
>            
>     >    >> > > direct submission to Greg; I'm still refining my workflow.     
>          
>     >    >> >                                                                 
>            
>     >    >> > Ok, then to level set some expectations:                         
>          
>     >    >> >                                                                 
>            
>     >    >> > Have you actually confirmed that the code you have submitted
>     compiles   
>     >    >> > and does fix the bug you reported?                               
>          
>     >    >> >                                                                 
>            
>     >    >> > Expectation is that you run the reproducer on top of drm-tip and
>     see   
>     >    >> a                                                                 
>            
>     >    >> > crash where you pick the dmesg/KASAN splat from, then you run
>     drm-tip   
>     >    >> > with the patch you have prepared and there is no crash.         
>            
>     >                                                                         
>            
>     >    >> Exactly.                                                           
>          
>     >                                                                         
>            
>     >    >> Before any further submission, please let's get back to square 0
>     here.   
>     >                                                                         
>            
>     >    >> 0. Please file a bug to our gilab/issues:                         
>            
>     >    >> [4]https://drm.pages.freedesktop.org/intel-docs/
>     how-to-file-i915-bugs.html
>     >                                                                         
>            
>     >    >> Do that against the drm-tip branch and provide all the log
>     information   
>     >    >> from your experiments.                                             
>          
>     >                                                                         
>            
>     >    >> 1. If you have a proposed patch, also please confirm that it
>     actually     
>     >    >> fix                                                               
>            
>     >    >> the issues that you are solving.                                   
>          
>     >                                                                         
>            
>     >    >> 2. Whenever using AI to help you with the code please ensure you
>     comply   
>     >    >> with this:                                                         
>          
>     >                                                                         
>            
>     >    >> Documentation/process/generated-content.rst                       
>            
>     >                                                                         
>            
>     >    >> Thanks,                                                           
>            
>     >    >> Rodrigo.                                                           
>          
>     >                                                                         
>            
>     >    >> >                                                                 
>            
>     >    >> > Regards, Joonas                                                 
>            
>     >
>     > References
>     >
>     >    Visible links
>     >    1. mailto:sosohero200@gmail.com
>     >    2. http://freedesktop.org/
>     >    3. mailto:rodrigo.vivi@intel.com
>     >    4. https://drm.pages.freedesktop.org/intel-docs/
>     how-to-file-i915-bugs.html
>

Re: AI slop security report against i915 (Was: Re: [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma)

[Greg KH]

On Thu, Mar 26, 2026 at 08:54:53AM +0200, Joonas Lahtinen wrote:
> (+ Adding back security mailing list (where this started) and LKML for them
> to be aware of any further bogus security reports from the author)

Ugh, I was kind of thinking this might be the case based on the original
interactions here, but was willing to give the benifit of the doubt.

Time to go reset the "Days since we recieved AI slop reports" counter
back to 0...

thanks for following through on this.

greg k-h

✗ LGCI.VerificationFailed: failure for drm/i915/gem: Fix UAF race in eb_relocate_vma

[Patchwork]

== Series Details ==

Series: drm/i915/gem: Fix UAF race in eb_relocate_vma
URL   : https://patchwork.freedesktop.org/series/163841/
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!

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Ville Syrjälä]

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

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Linus Torvalds]

On Thu, 26 Mar 2026 at 05:32, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> Should we not do something like this?
>
> if (likely(vma && vma->vm == vm))
>         vma = i915_vma_tryget(vma);
> + else
> +       vma = NULL;

That looks much better. Returning a vma that you looked up inside rcu
without gettin ga reference to it looks very wrong.

                  Linus

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Linus Torvalds]

On Thu, 26 Mar 2026 at 05:32, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> 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.

The fix for this seems to have gotten lost and wasn't in the recent
drm pull request.

I can just fix it up by myself, but it would be good to have proper
authorship and sign-off. Please?

             Linus

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Yassine Mounir]

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

Hi Linus,

Thank you for the follow-up. I'm more than happy to provide the sign-off
for proper authorship.

Here is the patch with my sign-off:

Signed-off-by: Yassine Mounir sosohero200@gmail.com
<yassine.mounir.source@gmail.com>
------------------------------

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 1234567..890abc 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -865,6 +865,8 @@
eb_lookup_vma(...) vma = radix_tree_lookup(&vm->va, handle); if (likely(vma
&& vma->vm == vm)) vma = i915_vma_tryget(vma);

   -

   else
   -

   vma = NULL;

   rcu_read_unlock();

   if (likely(vma))

Best regards, Yassine (toji1)


On Fri, 3 Apr 2026 at 18:12, Linus Torvalds <torvalds@linuxfoundation.org>
wrote:

> On Thu, 26 Mar 2026 at 05:32, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > 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.
>
> The fix for this seems to have gotten lost and wasn't in the recent
> drm pull request.
>
> I can just fix it up by myself, but it would be good to have proper
> authorship and sign-off. Please?
>
>              Linus
>

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

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Yassine Mounir]

Hi Linus,

Thank you for the follow-up. I'm more than happy to provide the
sign-off for proper authorship. It is an honor to contribute.

Here is the patch with the official sign-off:

Signed-off-by: Yassine Mounir sosohero200@gmail.com

________________________________

drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 ++ 1 file changed, 2
insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 1234567..890abc
100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -865,6 +865,8 @@
eb_lookup_vma(...) vma = radix_tree_lookup(&vm->va, handle); if
(likely(vma && vma->vm == vm)) vma = i915_vma_tryget(vma);

else

vma = NULL;

rcu_read_unlock();

if (likely(vma))

Best regards, Yassine (Toji1)


On Fri, 3 Apr 2026 at 18:12, Linus Torvalds
<torvalds@linuxfoundation.org> wrote:
>
> On Thu, 26 Mar 2026 at 05:32, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > 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.
>
> The fix for this seems to have gotten lost and wasn't in the recent
> drm pull request.
>
> I can just fix it up by myself, but it would be good to have proper
> authorship and sign-off. Please?
>
>              Linus

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Joonas Lahtinen]

Quoting Linus Torvalds (2026-04-04 01:12:17)
> On Thu, 26 Mar 2026 at 05:32, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > 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.
> 
> The fix for this seems to have gotten lost and wasn't in the recent
> drm pull request.
> 
> I can just fix it up by myself, but it would be good to have proper
> authorship and sign-off. Please?

Will include a proper patch in next -fixes PR.

The big question is, what stance to take on a value of AI generated low
quality reproducer code which was accompanied by wall of AI slop which
caused hours of time get wasted on debunking the hallucinations?

If the reproducer was sent verbatim with "AI claims this code crashes on
downstream kernel X-Y.Z on my machine W, I have no idea why because
it's AI generated." that would have been one thing.

However no proof has been even provided that it crashes on any kernel,
yet alone mainline. All there is AI ramblings claiming hard system lockup
while describing mouse cursor to be moving doesn't add up. Just like nothing
about the report adds up (like suddenly claiming the problem to equally
reproduce inside QEMU where i915 is not loaded).

"Reported-by" seems overly generous for causing hours to be wasted
debunking false AI hallucinated claims? At most it lead to manual
reviews where Ville finds a potential bug which may or may not be
connected in any way to the claimed crash which may not have ever
happened.

Should there be any tags applied? "Badly-reported-by"?

Regards, Joonas

> 
>              Linus

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Linus Torvalds]

On Tue, 7 Apr 2026 at 09:38, Joonas Lahtinen
<joonas.lahtinen@linux.intel.com> wrote:
>
> The big question is, what stance to take on a value of AI generated low
> quality reproducer code which was accompanied by wall of AI slop which
> caused hours of time get wasted on debunking the hallucinations?

I don't th8nk there are any good rules.

Some of the AI reports we get are great, with no slop in sight and
finding really subtle and real bugs.

And others are very much not.

In general, I don't think that's all that different from bug reports
from actual humans ;^/

So I'd suggest just fixing the bugs that are noticed, and giving
credit appropriate to how good the report was.

           Linus

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Joonas Lahtinen]

Quoting Linus Torvalds (2026-04-07 19:46:42)
> So I'd suggest just fixing the bugs that are noticed, and giving
> credit appropriate to how good the report was.

I've sent out v3 of the patch[1]. I think it should be fine for you to
simply drop or revert the version you included in -rc7.

As per Sima's analysis attached to the patch, the race for wrong VM
has not been possible to hit since 2021. And the refcount error
potentially leading to UAF accordingly is only relevant for drm-tip
codebase between 2020 and 2021.

So instead of being included in -fixes reverting your version and
allowing the v3 patch to get merged through normal means to v7.1 would
be better in case there happens to be some regression. It can then be
backported to the old kernels accordingly.

Regards, Joonas

[1] https://lore.kernel.org/intel-gfx/20260408110551.84120-1-joonas.lahtinen@linux.intel.com/

> 
>            Linus

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Linus Torvalds]

On Wed, 8 Apr 2026 at 04:15, Joonas Lahtinen
<joonas.lahtinen@linux.intel.com> wrote:
>
> I've sent out v3 of the patch[1]. I think it should be fine for you to
> simply drop or revert the version you included in -rc7.

No.

That code was MISLEADING GARBAGE.

At least now it does something sane for a situation that it tests for,
rather than "it tests for a situation that cannot happen, and then
does insane things".

Because "that cannot happen" is not an argument for doing insane things.

If it cannot happen, the test should simply not exist.

                 Linus

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Joonas Lahtinen]

Quoting Linus Torvalds (2026-04-08 18:38:00)
> On Wed, 8 Apr 2026 at 04:15, Joonas Lahtinen
> <joonas.lahtinen@linux.intel.com> wrote:
> >
> > I've sent out v3 of the patch[1]. I think it should be fine for you to
> > simply drop or revert the version you included in -rc7.
> 
> No.
> 
> That code was MISLEADING GARBAGE.

Yes, there was clearly a bug introduced at the time of adding the
vma->vm == vm check where zeroing vma was missed if only that part of
check failed. However the vma->vm == vm part can't have failed since
d4433c7600f7.

> At least now it does something sane for a situation that it tests for,
> rather than "it tests for a situation that cannot happen, and then
> does insane things".
> 
> Because "that cannot happen" is not an argument for doing insane things.

Maybe the commit wording was bad if you got that impression, but that was
never argued.

Argument was to amend the zeroing with WARN_ON_ONCE to check for the
"not supposed to happen scenario" in order to get a splat if we ever hit
that scenario.

> If it cannot happen, the test should simply not exist.

If you are happier, in mainline we can just skip the else part
completely and just reduce the check to if (likely(vma)) and skip
the whole vma->vm == vm part and not need the else branch at all.

Do you want that to be sent as part of -fixes then?

Regards, Joonas

> 
>                  Linus

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Linus Torvalds]

On Wed, 8 Apr 2026 at 09:24, Joonas Lahtinen
<joonas.lahtinen@linux.intel.com> wrote:
>
> Yes, there was clearly a bug introduced at the time of adding the
> vma->vm == vm check where zeroing vma was missed if only that part of
> check failed. However the vma->vm == vm part can't have failed since
> d4433c7600f7.

Yes, I'm perfectly fine with the change to just remove that chgeck
entirely (and then obviously the "set vma to NULL' addition goes
away).

I'm just saying that we don't just remove the new "set vma to NULL",
because that pattern of checking for something - and then doing the
wrong thing - is fundamentally wrong and misleading.

               Linus

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Joonas Lahtinen]

Quoting Linus Torvalds (2026-04-09 18:45:23)
> On Wed, 8 Apr 2026 at 09:24, Joonas Lahtinen
> <joonas.lahtinen@linux.intel.com> wrote:
> >
> > Yes, there was clearly a bug introduced at the time of adding the
> > vma->vm == vm check where zeroing vma was missed if only that part of
> > check failed. However the vma->vm == vm part can't have failed since
> > d4433c7600f7.
> 
> Yes, I'm perfectly fine with the change to just remove that chgeck
> entirely (and then obviously the "set vma to NULL' addition goes
> away).

Do you prefer for me to include a revert for the vma = NULL change in
the -next PR?

Including it in the simplification patch would have caused conflits
galore because the original change didn't come from our development
tree and didn't want to backmerge -rc7 there.

Regards, Joonas

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Matthew Brost]

On Tue, Apr 07, 2026 at 09:46:42AM -0700, Linus Torvalds wrote:
> On Tue, 7 Apr 2026 at 09:38, Joonas Lahtinen
> <joonas.lahtinen@linux.intel.com> wrote:
> >
> > The big question is, what stance to take on a value of AI generated low
> > quality reproducer code which was accompanied by wall of AI slop which

The reproducers from what I've seen are complete slot.

> > caused hours of time get wasted on debunking the hallucinations?
> 
> I don't th8nk there are any good rules.
> 
> Some of the AI reports we get are great, with no slop in sight and
> finding really subtle and real bugs.
> 
> And others are very much not.

+1?

I dealt with some complete AI slop today reporting a hallucination.
It was a subtle reference-counting issue that, if well documented,
probably shouldn’t have been flagged. IMO, it’s an opportunity to clean
up the code or at least document why it works. Yes, annoying, even more
so if less actively maintained status—but in general it flags hand-wavy,
questionable code that needs an explanation.

Conversely, today on fresh code, Sashiko immediately flagged very
subtle, likely nearly impossible-to-hit issues, which I appreciated, and
closed.

> 
> In general, I don't think that's all that different from bug reports
> from actual humans ;^/

So yea, problably worth a look at reports unless want to orphan code.

Matt

> 
> So I'd suggest just fixing the bugs that are noticed, and giving
> credit appropriate to how good the report was.
> 
>            Linus

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Linus Torvalds]

On Thu, 9 Apr 2026 at 01:05, Matthew Brost <matthew.brost@intel.com> wrote:
>
> I dealt with some complete AI slop today reporting a hallucination.
> It was a subtle reference-counting issue that, if well documented,
> probably shouldn’t have been flagged. IMO, it’s an opportunity to clean
> up the code or at least document why it works. Yes, annoying, even more
> so if less actively maintained status—but in general it flags hand-wavy,
> questionable code that needs an explanation.

Some of the slop reports are indeed "that code may work well, but it
looks odd because it has a pattern that is typically a bug".

And others are _just_ pure hallucinations.

But I think that lately quite a noticeable percentage of reports have
become very much valid. As you say, Sashiko tends to be quite good.
Even when it flags something unnecessarily and there's no actual
problem, there's likely to be a reason for the question.

And we've seen some truly stellar reports too. Things that are deep
and subtle, and the AI is 100% correct.

So anybody who thinks that all AI is slop is in denial about the current state.

             Linus

Re: [PATCH v2] [PATCH v2] drm/i915/gem: Fix UAF race in eb_relocate_vma

[Simona Vetter]

On Tue, Apr 07, 2026 at 07:38:06PM +0300, Joonas Lahtinen wrote:
> Quoting Linus Torvalds (2026-04-04 01:12:17)
> > On Thu, 26 Mar 2026 at 05:32, Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > 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.
> > 
> > The fix for this seems to have gotten lost and wasn't in the recent
> > drm pull request.
> > 
> > I can just fix it up by myself, but it would be good to have proper
> > authorship and sign-off. Please?
> 
> Will include a proper patch in next -fixes PR.
> 
> The big question is, what stance to take on a value of AI generated low
> quality reproducer code which was accompanied by wall of AI slop which
> caused hours of time get wasted on debunking the hallucinations?
> 
> If the reproducer was sent verbatim with "AI claims this code crashes on
> downstream kernel X-Y.Z on my machine W, I have no idea why because
> it's AI generated." that would have been one thing.
> 
> However no proof has been even provided that it crashes on any kernel,
> yet alone mainline. All there is AI ramblings claiming hard system lockup
> while describing mouse cursor to be moving doesn't add up. Just like nothing
> about the report adds up (like suddenly claiming the problem to equally
> reproduce inside QEMU where i915 is not loaded).
> 
> "Reported-by" seems overly generous for causing hours to be wasted
> debunking false AI hallucinated claims? At most it lead to manual
> reviews where Ville finds a potential bug which may or may not be
> connected in any way to the claimed crash which may not have ever
> happened.
> 
> Should there be any tags applied? "Badly-reported-by"?

[Joonas pinged me on irc whether there's a drm stake on this but then
immediately dropped, so here we go.]

I wouldn't use this tag, feels like insulting people on the record for no
gain.

That aside I'd go with Linus' general take in his reply to credit any bug
reports as you see fit. Personally maybe Reported-by: Ville (if someone
else types up the patch) and References: for the overall thread for
context. There's no requirement to thank people who just wasted your time.

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