CVE-2026-89960 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm()
In vfio_ap_mdev_set_kvm(), kvm->arch.crypto.pqap_hook is set to &matrix_mdev->pqap_hook 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.pqap_hook pointing at the failing matrix_mdev instead of the mdev that legitimately owns the KVM.
Since matrix_mdev->kvm is never set on this error path, vfio_ap_mdev_unset_kvm() will not clean up the hook when matrix_mdev is later closed. If matrix_mdev is subsequently freed, any PQAP instruction executed by the guest will dereference the stale pointer through pqap_hook_rwsem, resulting in a use-after-free.
Since kvm->arch.crypto.pqap_hook is only set in the vfio_ap_mdev_set_kvm() function and is cleared in the vfio_ap_mdev_unset_kvm() function, a check for 'kvm->arch.crypto.pqap_hook != NULL' is all that is needed to determine whether it belongs to another mdev. This will alleviate the need to iterate the matrix_dev->mdev_list list to see if the kvm object is assigned to another mdev.This was introduced in v3 to alleviate the need to take the mdevs_lock while iterating the list; however, this did not prevent a potential race condition.
The pqap_hook_rwsem(write) is now performed inside get_update_locks_for_kvm(), which is updated to acquire pqap_hook_rwsem(write) between kvm->lock and mdevs_lock. This ordering is consistent with the PQAP intercept path, which acquires pqap_hook_rwsem in read mode while srcu is held under vcpu->mutex, establishing the dependency: kvm->lock -> vcpu->mutex -> srcu -> pqap_hook_rwsem(read).
The pqap_hook_rwsem is now released inside the release_update_locks_for_kvm(), which is updated to release pqap_hook_rwsem(write) between mdevs_lock and kvm->lock.
Additionally, kvm_put_kvm() in vfio_ap_mdev_unset_kvm() is moved after release_update_locks_for_kvm(). Previously it was called while kvm->lock was held; if it were ever the last reference, kvm_destroy_vm() would run under kvm->lock, which would deadlock.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel vulnerability in the s390 vfio-ap subsystem involves a critical use-after-free condition arising from improper pointer management during error handling within the vfio_ap_mdev_set_kvm function. This flaw occurs when attempting to assign a matrix mediated device to a KVM instance that is already associated with another device. The core technical failure lies in the sequence of operations where kvm->arch.crypto.pqap_hook is assigned to point at the new matrix_mdev before acquiring necessary update locks and verifying for conflicting assignments. If a conflict is detected, causing the function to return an -EPERM error code, the pqap_hook pointer remains pointing to the failing matrix_mdev rather than being restored to its previous valid state or cleared. This leaves the kernel with a stale reference that does not correspond to any legitimate owner of the KVM instance at that moment.
The operational impact of this defect is severe, leading directly to a use-after-free scenario when the guest executes PQAP instructions. Because matrix_mdev->kvm is never set during this failed error path, the cleanup routine vfio_ap_mdev_unset_kvm does not recognize the need to nullify or clean up the hook pointer associated with that specific device. Consequently, if the failing matrix_mdev structure is subsequently freed by memory management routines, any subsequent PQAP instruction executed within the guest environment will attempt to dereference the pqap_hook through pqap_hook_rwsem using a pointer that now references deallocated memory. This results in undefined behavior, potential kernel crashes, or arbitrary code execution depending on how the freed memory has been reallocated and utilized by other subsystems.
From an industry standards perspective, this vulnerability is classified under CWE-416, Use After Free, as it involves accessing memory after it has been released due to a logic error in resource management. Furthermore, the issue relates to improper locking and synchronization mechanisms which can be mapped to ATT&CK techniques involving exploitation of race conditions or timing attacks within kernel space, although primarily this is a local privilege escalation vector if an attacker can trigger the specific sequence leading to the stale pointer dereference. The root cause stems from an attempt introduced in version 3 to optimize performance by avoiding iteration over the matrix_dev->mdev_list and taking mdevs_lock during every check. While intended to alleviate locking overhead, this optimization inadvertently created a race condition where state consistency was not maintained across error paths.
The resolution involves restructuring the lock acquisition order and ensuring proper cleanup on all execution paths. The pqap_hook_rwsem write operation is now performed inside get_update_locks_for_kvm, which acquires the semaphore between kvm->lock and mdevs_lock. This ordering aligns with the dependency chain established by the PQAP intercept path, where pqap_hook_rwsem is acquired in read mode while srcu is held under vcpu->mutex, creating a consistent hierarchy of kvm->lock to vcpu->mutex to srcu to pqap_hook_rwsem. By enforcing this strict lock ordering, the kernel prevents deadlocks and ensures that state changes are atomic with respect to these synchronization primitives.
Additionally, the release logic has been corrected in vfio_ap_mdev_unset_kvm by moving the kvm_put_kvm call after release_update_locks_for_kvm. Previously, calling kvm_put_kvm while holding kvm->lock could lead to a deadlock if it was the last reference, triggering kvm_destroy_vm under the lock context which violates locking rules. The fix ensures that all locks are released before decrementing references or performing cleanup operations that might trigger further kernel internal calls requiring those same locks. This comprehensive approach eliminates both the use-after-free vulnerability and potential deadlocks associated with incorrect lock release sequences in the vfio-ap subsystem.