UBUNTU-CVE-2026-89960: Use After Free

In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: fix stale pqaphook pointer on error in vfioapmdevsetkvm() In vfioapmdevsetkvm(), kvm->arch.crypto.pqaphook is set to &matrixmdev->pqaphook before the update locks are acquired and the mdev list is checked for a conflicting assignment. If another mdev is already attached to the same KVM instance, the function returns -EPERM without restoring the hook pointer, leaving kvm->arch.crypto.pqaphook pointing at the failing matrixmdev instead of the mdev that legitimately owns the KVM. Since matrixmdev->kvm is never set on this error path, vfioapmdevunsetkvm() will not clean up the hook when matrixmdev is later closed. If matrixmdev is subsequently freed, any PQAP instruction executed by the guest will dereference the stale pointer through pqaphookrwsem, resulting in a use-after-free. Since kvm->arch.crypto.pqaphook is only set in the vfioapmdevsetkvm() function and is cleared in the vfioapmdevunsetkvm() function, a check for 'kvm->arch.crypto.pqaphook != NULL' is all that is needed to determine whether it belongs to another mdev. This will alleviate the need to iterate the matrixdev->mdevlist list to see if the kvm object is assigned to another mdev.This was introduced in v3 to alleviate the need to take the mdevslock while iterating the list; however, this did not prevent a potential race condition. The pqaphookrwsem(write) is now performed inside getupdatelocksforkvm(), which is updated to acquire pqaphookrwsem(write) between kvm->lock and mdevslock. This ordering is consistent with the PQAP intercept path, which acquires pqaphookrwsem in read mode while srcu is held under vcpu->mutex, establishing the dependency: kvm->lock -> vcpu->mutex -> srcu -> pqaphookrwsem(read). The pqaphookrwsem is now released inside the releaseupdatelocksforkvm(), which is updated to release pqaphookrwsem(write) between mdevslock and kvm->lock. Additionally, kvmputkvm() in vfioapmdevunsetkvm() is moved after releaseupdatelocksforkvm(). Previously it was called while kvm->lock was held; if it were ever the last reference, kvmdestroyvm() would run under kvm->lock, which would deadlock.