GPU VulnDB

Database/Kernel, userspace & hypervisor

KVM x86/mmu: lockless aging walk re-reads the rmap and can follow a pte_list_desc chain being freed

CVSS 8.8CVE-2026-89928Kernel, userspace & hypervisorcurated

Impact

__kvm_rmap_lock() deliberately skips taking the rmap lock when the rmap is empty, on the invariant that no lockless walker will then walk it. kvm_rmap_age_gfn_range() ignored that return value and entered the iterator anyway, which re-read rmap_head->val; if a writer populated the rmap in between, the aging path walked a KVM_RMAP_MANY chain it never locked, while a writer holding mmu_lock for write can free that chain via kmem_cache_free(). The result is a slab use-after-free in the host kernel, reachable on hosts built with CONFIG_KVM_MMU_LOCKLESS_AGING=y, and the empty path re-enables preemption so the window can span an arbitrary scheduling delay. On a virtualized GPU host - vGPU or passthrough VMs from multiple tenants - host-side memory corruption is a cross-tenant problem, and patching it means rebooting a hypervisor whose VMs have to be moved first. The fix makes the lockless walk consume the value returned by the lock instead of re-reading it.

Who can reach it

Local on an x86 KVM host. Triggered by memory pressure and guest memory activity racing the MMU notifier aging path; a guest can influence both sides. Requires no host credentials beyond running a VM on the host.

What to do

Take the linked stable commits or a patched distribution kernel, then drain guests and reboot each hypervisor. Hosts built without CONFIG_KVM_MMU_LOCKLESS_AGING are not exposed to the lockless aging path, which is worth checking before scheduling a fleet-wide window.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.