Re: hunting memory corruption bug in 6.18.x

[Yosry Ahmed]

On Mon, Oct 19, 2026 at 8:35 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, 19 Oct 2026 17:22:37 +0200 Nikola Ciprich <nikola.ciprich@xxxxxxxxxxx> wrote:
>
> > >
> > > Sure! And I have more good news: after applying 55780d8a1dcc
> > > to 6.18.56, I was able to perform more than 30 migrations without
> > > a glitch. After booting back into 6.18.56 without it, both VMs
> > > crashed within 2-3 migrations. Furthermore, some memory apparently
> > > got corrupted on one of the hosts, since various commands started
> > > crashing too:
> > >
> > > [  303.466091] traps: systemd-logind[3085] trap invalid opcode ip:7f7b5667e616 sp:7ffe1afdec38 error:0 in libsystemd-shared-252.so[7e616,7f7b5666d000+22e000]
> > > [  303.493810] traps: systemd-coredum[11269] trap invalid opcode ip:7fc6bf67f614 sp:7ffc075da958 error:0 in libsystemd-shared-252.so[7f614,7fc6bf66d000+22e000]
> > > [  377.528955] traps: systemd[5607] trap invalid opcode ip:7f791447e616 sp:7ffe83e61cf8 error:0 in libsystemd-shared-252.so[7e616,7f791446d000+22e000]
> > > [  377.556993] traps: systemd-coredum[12080] trap invalid opcode ip:7f97ce07f614 sp:7ffe28b56a88 error:0 in libsystemd-shared-252.so[7f614,7f97ce06d000+22e000]
> > > [ 3746.173043] traps: hostnamectl[45846] trap invalid opcode ip:7fe00cc7f614 sp:7fff89916e48 error:0 in libsystemd-shared-252.so[7f614,7fe00cc6d000+22e000]
> > > [ 3746.202305] traps: systemd-coredum[45847] trap invalid opcode ip:7f7fe9e7f614 sp:7ffea227cfa8 error:0 in libsystemd-shared-252.so[7f614,7f7fe9e6d000+22e000]
> > > [ 3750.581940] traps: systemctl[45903] trap invalid opcode ip:7fbb8967f614 sp:7fff733e5748 error:0 in libsystemd-shared-252.so[7f614,7fbb8966d000+22e000]
> > > [ 3750.612651] traps: systemd-coredum[45904] trap invalid opcode ip:7f90d347f614 sp:7ffdc7f55148 error:0 in libsystemd-shared-252.so[7f614,7f90d346d000+22e000]
> > >
> > > I'm not sure if this is of any use, but I collected a vmcore of
> > > this state by intentionally crashing the host via /proc/sysrq-trigger.
> > >
> > > Anyway, I'll give 55780d8a1dcc some more migration rounds, but it looks
> > > promising.
> >
> > 500+ migrations back and forth, no issues. I consider this solved and am rolling
> > out the patched kernel; I’ll report if anything new turns up.

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?

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