CVE-2026-89928

What it is

In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Consume the locked rmap value in the lockless rmap walk __kvm_rmap_lock() deliberately elides the rmap lock when it observes an empty rmap. In that case kvm_rmap_lock_readonly() 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 mmu_lock for write, and are mutually exclusive. kvm_rmap_age_gfn_range() ignores the returned value and unconditionally enters for_each_rmap_spte_lockless(). The iterator started with rmap_get_first(), which re-reads rmap_head->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 KVM_RMAP_MANY rmap this leaves the walker following a pte_list_desc chain that it never locked. A writer holding mmu_lock for write may free that chain (e.g. kvm_zap_all_rmap_sptes() on the recycle path, or any rmap zap) via kmem_cache_free() while the walk is in progress, giving a slab use-after-free. Nothing serialises the two: the aging path runs without mmu_lock when CONFIG_KVM_MMU_LOCKLESS_AGING=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 rmap_get_first() into __rmap_get_first(), which starts an iterator from an already-read rmap value, and make for_each_rmap_spte_lockless() take that value and call __rmap_get_first() directly. kvm_rmap_age_gfn_range() passes the value returned by kvm_rmap_lock_readonly(): when the lock was elided the value is zero, __rmap_get_first() 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.

At a glance

Exploitability

Can be exploited locally on the machine with a low-privilege account. High risk of data exposure, data tampering, service disruption.

Exploit odds

0.2% chance of exploitation in the next 30 days (EPSS).

Fix

No patch or advisory is linked yet. Look at mitigations or restrict exposure.

Timeline

1. 2026-09-11 19:38 UTC ReservedThe CVE id was reserved by its CNA
2. 2026-09-16 11:17 UTC PublishedDisclosed publicly on CVE.org and NVD
3. 2026-10-19 09:18 UTC Last updatedMost recent change to the record

Details

Published

2026-09-16 11:17 UTC

Last modified

2026-10-19 09:18 UTC

Exploit probability

0.2% · EPSS, next 30 days

Record status

Received

Attack profile CVSS 3.1 · 8.8

Attack vector

Local

Complexity

Low

Privileges needed

Low

User interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High