Re: hunting memory corruption bug in 6.18.x

From: Borislav Petkov

Date: Thu Oct 15 2026 - 18:12:26 EST


On Thu, Oct 15, 2026 at 11:10:24AM +0200, Nikola Ciprich wrote:
> I don’t have the vmcore for 20261008-lbxv1f (that box got fenced), but I have
> a full vmcore for 20260930-flev1c, which is the same bug: same crash in the
> dcache hash walk, and the same bad value — flev1c has 0x0fffffff0c930020
> (top byte sheared),

Bah, I'm looking at the dmesg from that one:

[378185.135721] Oops: general protection fault, probably for non-canonical address 0xfffffff0c930038: 0000 [#1] SMP NOPTI

and that says non-canonical but I cannot see that there are 7 leading f-s, not
8. :)

The register dump shows it better:

[378185.223709] RAX: 0fffffff0c930020 RBX: 0fffffff0c930020 RCX: 000000000000000b
^

...

> So on flev1c it looks less like “a dentry pointer went funky” and more like
> “some other structure’s content got written into dcache (and other) frames,
> one copy landing in a hash bucket.” Does that header signature
> (0x00ff00ff00100010 / 0xbdcc802700060042) ring a bell for any structure?

No idea. It looks like some weird corruption happened somewhere and then that
propagated into the hash list... but what do I know.

> Happy to run anything else against this vmcore — struct page dumps for the
> affected frames, the full record contents, the physical-search hit list, etc.

What you can do is, have AI go over all crash dumps you have and ask it to
scour and find patterns in the dumps and perhaps give you theories how that
corruption might've happen. And compare the dumps and see if there are common
patterns...

>From all the gibberish it would spit, sometimes there are interesting hints
there to chase forward.

Other than that, this looks really weird.

And I don't see any MCEs getting logged..., or? Anything related to hw errors?


The 20261009-lbxv1g one looks even weirder:

[ 938.693886] BUG: unable to handle page fault for address: 00068fff008b0058

Some funky pattern got eaten...

The top nybble zeroed is also present in the 20260905-adav2i case.

Strange...

Thx.

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette