CVE-2026-89928: KVM: x86/mmu: Consume the locked rmap value in the lockless rmap walk

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/mmu: Consume the locked rmap value in the lockless rmap walk

kvmrmaplock() deliberately elides the rmap lock when it observes an empty rmap. In that case kvmrmaplockreadonly() also re-enables preemption and returns zero, so the caller holds neither the rmap lock nor a preemption reference. The elision documents the invariant it relies on:

Elide the lock if the rmap is empty, as lockless walkers (read-only mode) don't need to (and can't) walk an empty rmap, nor can they add entries to the rmap. I.e. the only paths that process empty rmaps do so while holding mmulock for write, and are mutually exclusive.

kvmrmapagegfnrange() ignores the returned value and unconditionally enters foreachrmapsptelockless(). The iterator started with rmapgetfirst(), which re-reads rmaphead->val rather than using the value returned by the lock. If a writer populates the rmap between the lock's read and the iterator's re-read, the aging path walks the newly installed rmap without holding its lock.

For a KVMRMAPMANY rmap this leaves the walker following a ptelistdesc chain that it never locked. A writer holding mmulock for write may free that chain (e.g. kvmzapallrmapsptes() on the recycle path, or any rmap zap) via kmemcachefree() while the walk is in progress, giving a slab use-after-free. Nothing serialises the two: the aging path runs without mmulock when CONFIGKVMMMULOCKLESSAGING=y, and the rmap lock that would otherwise exclude the writer was elided. Because the empty path re-enables preemption, the interval between the two reads can span an arbitrary scheduling delay.

Fix the class of bug by having the lockless walk consume the value returned by the lock instead of re-reading the rmap. Split rmapgetfirst() into rmapgetfirst(), which starts an iterator from an already-read rmap value, and make foreachrmapsptelockless() take that value and call rmapgetfirst() directly. kvmrmapagegfnrange() passes the value returned by kvmrmaplockreadonly(): when the lock was elided the value is zero, rmapgetfirst() returns NULL, and the walk is skipped. No lockless walker re-reads the rmap, so the lock-elision invariant cannot be violated, and no lock()-without-paired-unlock() path is added to the aging code.