Re: hunting memory corruption bug in 6.18.x

[Yosry Ahmed]

On Mon, Oct 19, 2026 at 12:53 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> On Mon, Oct 19, 2026 at 11:15 AM Borislav Petkov <bp@xxxxxxxxx> wrote:
> >
> > On Mon, Oct 19, 2026 at 11:00:00AM -0700, Yosry Ahmed wrote:
> > > Right, but this is for new patches that get merged into Linus's tree,
> > > what about existing patches? Any way to retrigger that workflow?
> >
> > You take your patch, apply it to the stable trees here:
> >
> > https://www.kernel.org/category/releases.html
> >
> > and send the applied and tested version it to <stable@xxxxxxxxxx>.
> >
> > I.e., you backport it yourself. :)
>
> Will do, I have done manual backports before but only for conflicts. I
> was more asking if I need to send the patch to all branches or if it
> will be automatically backported to the others if there are no
> conflicts.

Actually, it doesn't matter. I think only v6.18 is affected. I think
the problem was introduced in 5a1a726e68ff ("KVM: x86: Use
KVM_REQ_RECALC_INTERCEPTS to react to CPUID updates"). This commit
deferred the initial intercepts calculation to the first KVM_RUN,
making it possible to calculate the intercepts while L2/vmcb02 is
active without calculating the intercepts in L1. Before that, I
believe the bug was indeed benign in practice (I think a VMM can still
trigger it by going from an Intel CPUID to an AMD CPUID after
restoring into L2 but before KVM_RUN).