Thanks a lot for re-reporting this: it was fun to work it out.
It's not a rootkit, it's harmless, but we ought to fix the noise.
Simple patch below, but let me explain more verbosely first.
What was really interesting in your report was that the address
is so close to that in OGAWA-San's report. I had a look at that
page on my x86_64 boxes, and they have lots of 0x90s there too.
It's just some page alignment filler that x86_64 kernel startup
has missed cleaning up - patch below fixes that. There's no
security aspect to it: the entries were already not-present,
they just generate this noise by triggering the pmd_bad test.
But why do you occasionally see those messages (I never have)?
I was puzzled awhile because those tests are usually for user
address space, but this is up in kernel address space: in the
modules area. Ah, vmalloc.c uses them: it's almost coincidence,
but those user space tests do work on the vmalloc and modules
areas, though they'd fail on many other parts of the kernel
address space (because of pse and global and nx bits).
Those messages come just occasionally from unloading a module.
There's a years-old anomaly in vmalloc.c, that the allocation
routines add an empty guard page slot to the size, then the
freeing routines include that empty slot. (I've always thought
the guard page should be private to vmalloc.c, consistently left
out of the public size; but that would need wider changes.) When
it would occupy the first slot of a new page table, allocation won't
have assigned one, and freeing will then hit this "bad" pmd entry.
Hugh
[PATCH] x86: fix bad pmd ffff810000207xxx(9090909090909090)
OGAWA Hirofumi and Fede have reported rare pmd_ERROR messages:
mm/memory.c:127: bad pmd ffff810000207xxx(9090909090909090).
Initialization's cleanup_highmap was leaving alignment filler
behind in the pmd for MODULES_VADDR: when vmalloc's guard page
would occupy a new page table, it's not allocated, and then
module unload's vfree hits the bad 9090 pmd entry ...
