In the Linux kernel, the following vulnerability has been resolved:
KVM: Reject attempts to consume or refresh inactive gfntopfn_cache
Reject kvmgpccheck() and kvmgpcrefresh() if the cache is inactive. Not checking the active flag during refresh is particularly egregious, as KVM can end up with a valid, inactive cache, which can lead to a variety of use-after-free bugs, e.g. consuming a NULL kernel pointer or missing an mmu_notifier invalidation due to the cache not being on the list of gfns to invalidate.
Note, "active" needs to be set if and only if the cache is on the list of caches, i.e. is reachable via mmunotifier events. If a relevant mmunotifier event occurs while the cache is "active" but not on the list, KVM will not acquire the cache's lock and so will not serailize the mmunotifier event with active users and/or kvmgpc_refresh().
A race between KVMXENATTRTYPESHAREDINFO and KVMXENHVMEVTCHN_SEND can be exploited to trigger the bug.
kvmxenhvmsetattr case KVMXENATTRTYPESHAREDINFO kvmgpcdeactivate kvmgpc_unmap gpc->valid = false gpc->khva = NULL gpc->active = false
Result: active = false, valid = false
kvmarchvmioctl case KVMXENHVMEVTCHNSEND kvmxenhvmevtchnsend kvmxensetevtchn kvmxensetevtchnfast kvmgpccheck return -EWOULDBLOCK because !gpc->valid kvmxensetevtchnfast return -EWOULDBLOCK kvmgpcrefresh hvatopfn_retry gpc->valid = true gpc->khva = not NULL
Result: active = false, valid = true
kvmarchvmioctl case KVMXENHVMEVTCHNSEND kvmxenhvmevtchnsend kvmxensetevtchn kvmxensetevtchnfast readlock gpc->lock kvmxenhvmsetattr case KVMXENATTRTYPESHAREDINFO mutexlock kvm->lock kvmxensharedinfoinit kvmgpcactivate gpc->khva = NULL kvmgpccheck [ Check passes because gpc->valid is still true, even though gpc->khva is already NULL. ] shinfo = gpc->khva pendingbits = shinfo->evtchnpending CRASH: testandsetbit(..., pending_bits)