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

[Simona Vetter <simona.vetter@ffwll.ch>]

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