Re: hunting memory corruption bug in 6.18.x

[Yosry Ahmed]

On Mon, Oct 19, 2026 at 10:58 AM Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, 19 Oct 2026 10:39:30 -0700 Yosry Ahmed <yosry@xxxxxxxxxx> 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.

Right, but this is for new patches that get merged into Linus's tree,
what about existing patches? Any way to retrigger that workflow?

>
> > >
> > > 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.