Re: hunting memory corruption bug in 6.18.x

[Andrew Morton <akpm@linux-foundation.org>]

On Mon, 19 Oct 2026 10:39:30 -0700 Yosry Ahmed <yosry@kernel.org> wrote:

> I am glad the commit fixed your problem!
> 
> >
> > Great, thanks.
> >
> > oops, we haven't been cc'ing Yosry.
> >
> > > Definitely a -stable candidate. Andrew, will you send it to Greg, or shall I?
> >
> > I volunteer Yosry or Sean ;)
> >
> > I think 55780d8a1dcc should be repackaged before sending over to the
> > -stable people.  Its changelog is very wrong: "The bug is benign
> > though".  Update the changelog to explain that the bug is in fact evil.
> > Otherwise -stable and further downstream won't understand why we sent
> > it to them and won't understand the impact.
> 
> It was found through code inspection, there weren't any symptoms, and
> I think I know why my analysis was incomplete. It assumes that
> svm_recalc_instruction_intercepts() already ran at least once for L1
> (vmcb01) to configure its intercepts, which generally must be the case
> (L1 must start L2), except during migration :')
> 
> About repackaging, yeah we can add a note about the new finding and
> the necessity of the backport. One question tho, is there a way to
> send a patch to "all" stable branch (the same effect as adding Cc:
> stable retroactively), or do I need to send separate backports to all
> open stable branches?

As far as I understand, a cc:stable and a Fixes: will result in it
being backported into every tree which has the Fixes: target commit.  

> >
> > And that repackaging would be an opportunity to add
> > Reported-by:/Closes:/Tested-by: you, which is the least we can do to
> > thank you for all this diligent work!
> 
> Will do.

Thanks.