In the Linux kernel, the following vulnerability has been resolved: KVM: Reject attempts to consume or refresh inactive gfntopfncache 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 mmunotifier 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 kvmgpcrefresh(). A race between KVMXENATTRTYPESHAREDINFO and KVMXENHVMEVTCHNSEND can be exploited to trigger the bug. 1. Deactivate shinfo cache: kvmxenhvmsetattr case KVMXENATTRTYPESHAREDINFO kvmgpcdeactivate kvmgpcunmap gpc->valid = false gpc->khva = NULL gpc->active = false Result: active = false, valid = false 2. Cause cache refresh: kvmarchvmioctl case KVMXENHVMEVTCHNSEND kvmxenhvmevtchnsend kvmxensetevtchn kvmxensetevtchnfast kvmgpccheck return -EWOULDBLOCK because !gpc->valid kvmxensetevtchnfast return -EWOULDBLOCK kvmgpcrefresh hvatopfnretry gpc->valid = true gpc->khva = not NULL Result: active = false, valid = true 3. Race ioctl KVMXENHVMEVTCHNSEND against ioctl KVMXENATTRTYPESHAREDINFO: 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(..., pendingbits)