{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-89960","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2026-09-11T19:38:34.778Z","datePublished":"2026-09-16T10:32:42.618Z","dateUpdated":"2026-09-16T14:40:40.451Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-09-16T14:40:40.451Z"},"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\ns390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm()\n\nIn vfio_ap_mdev_set_kvm(), kvm->arch.crypto.pqap_hook is set to\n&matrix_mdev->pqap_hook before the update locks are acquired and the\nmdev list is checked for a conflicting assignment. If another mdev is\nalready attached to the same KVM instance, the function returns -EPERM\nwithout restoring the hook pointer, leaving kvm->arch.crypto.pqap_hook\npointing at the failing matrix_mdev instead of the mdev that legitimately\nowns the KVM.\n\nSince matrix_mdev->kvm is never set on this error path,\nvfio_ap_mdev_unset_kvm() will not clean up the hook when matrix_mdev\nis later closed. If matrix_mdev is subsequently freed, any PQAP\ninstruction executed by the guest will dereference the stale pointer\nthrough pqap_hook_rwsem, resulting in a use-after-free.\n\nSince kvm->arch.crypto.pqap_hook is only set in the vfio_ap_mdev_set_kvm()\nfunction and is cleared in the vfio_ap_mdev_unset_kvm() function, a check\nfor 'kvm->arch.crypto.pqap_hook != NULL' is all that is needed to determine\nwhether it belongs to another mdev. This will alleviate the need to iterate\nthe matrix_dev->mdev_list list to see if the kvm object is assigned to\nanother mdev.This was introduced in v3 to alleviate the need to take the\nmdevs_lock while iterating the list; however, this did not prevent a\npotential race condition.\n\nThe pqap_hook_rwsem(write) is now performed inside\nget_update_locks_for_kvm(), which is updated to acquire\npqap_hook_rwsem(write) between kvm->lock and mdevs_lock. This ordering\nis consistent with the PQAP intercept path, which acquires pqap_hook_rwsem\nin read mode while srcu is held under vcpu->mutex, establishing the\ndependency: kvm->lock -> vcpu->mutex -> srcu -> pqap_hook_rwsem(read).\n\nThe pqap_hook_rwsem is now released inside the\nrelease_update_locks_for_kvm(), which is updated to release\npqap_hook_rwsem(write) between mdevs_lock and kvm->lock.\n\nAdditionally, kvm_put_kvm() in vfio_ap_mdev_unset_kvm() is moved\nafter release_update_locks_for_kvm(). Previously it was called while\nkvm->lock was held; if it were ever the last reference, kvm_destroy_vm()\nwould run under kvm->lock, which would deadlock."}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","baseScore":8.8,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"AV:L - The bug is reached by opening vfio-ap mdev fds and linking them to a KVM instance (KVM_DEV_VFIO_FILE_ADD/BIND_IOMMUFD) so vfio_ap_mdev_open_device() calls vfio_ap_mdev_set_kvm(), then by a guest PQAP(AQIC) intercept in handle_pqap(); that is a local VFIO/KVM path with no network or USB exposure.\nAC:L - An attacker who can open two vfio-ap mdevs against the same KVM deterministically hits the -EPERM conflict path that overwrites kvm->arch.crypto.pqap_hook without restoring it, then frees the failing mdev and issues PQAP from the still-running guest; the attacker controls every step, with no victim race or uncontrolled layout.\nPR:L - vfio_ap_mdev_set_kvm() and the PQAP intercept have no capable() gate; /dev/kvm and /dev/vfio nodes are routinely granted to an unprivileged qemu/kvm-group tenant with assigned vfio-ap mdevs, so host root is not required, and user namespaces cannot substitute for this path.\nUI:N - The attacker performs the conflicting VFIO attach, tears down the failing mdev, and executes PQAP in their own guest; prior administrator creation of vfio-ap mdevs is deployment configuration, not victim interaction during exploitation.\nS:C - A guest PQAP intercept on the host calls through kvm->arch.crypto.pqap_hook into a freed ap_matrix_mdev in the host vfio-ap driver, hijacking a host kernel function pointer and crossing the KVM/VFIO guest-to-host isolation boundary (VM escape).\nC:H - After the failing mdev is kvfree'd, handle_pqap() does pqap_hook = *vcpu->kvm->arch.crypto.pqap_hook, reading a function pointer from the freed ap_matrix_mdev; reclaiming that object yields an arbitrary kernel-read primitive, which kernel UAF guidance scores High.\nI:H - The intercept then invokes that recovered pointer as pqap_hook(vcpu); spraying the freed ap_matrix_mdev replaces the hook with an attacker-controlled address, enabling host kernel control-flow hijack and arbitrary write.\nA:H - The same stale-pointer dereference and call on the freed object causes a host kernel oops or panic when the guest issues PQAP, even if the function pointer is not fully hijacked."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["drivers/s390/crypto/vfio_ap_ops.c"],"versions":[{"version":"86956e70761b3292156d668e87126844334dd71b","lessThan":"eb6cc898501a004c0fa8aab951351d9c959b91cc","status":"affected","versionType":"git"},{"version":"86956e70761b3292156d668e87126844334dd71b","lessThan":"6a180adafc2a8a5fbe815985c71b2201e93ab5e1","status":"affected","versionType":"git"},{"version":"86956e70761b3292156d668e87126844334dd71b","lessThan":"fc069d00a0dbef40042fd681554d48dcd5a1d524","status":"affected","versionType":"git"},{"version":"86956e70761b3292156d668e87126844334dd71b","lessThan":"13bfc94eef389bd664ffc67b00184919902c938a","status":"affected","versionType":"git"},{"version":"86956e70761b3292156d668e87126844334dd71b","lessThan":"4400270ec0348d05dc0439d8f0130853ce7f9e20","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["drivers/s390/crypto/vfio_ap_ops.c"],"versions":[{"version":"5.15","status":"affected"},{"version":"0","lessThan":"5.15","status":"unaffected","versionType":"semver"},{"version":"6.6.157","lessThanOrEqual":"6.6.*","status":"unaffected","versionType":"semver"},{"version":"6.12.110","lessThanOrEqual":"6.12.*","status":"unaffected","versionType":"semver"},{"version":"6.18.51","lessThanOrEqual":"6.18.*","status":"unaffected","versionType":"semver"},{"version":"7.2.5","lessThanOrEqual":"7.2.*","status":"unaffected","versionType":"semver"},{"version":"7.3-rc1","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.15","versionEndExcluding":"6.6.157"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.15","versionEndExcluding":"6.12.110"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.15","versionEndExcluding":"6.18.51"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.15","versionEndExcluding":"7.2.5"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.15","versionEndExcluding":"7.3-rc1"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/eb6cc898501a004c0fa8aab951351d9c959b91cc"},{"url":"https://git.kernel.org/stable/c/6a180adafc2a8a5fbe815985c71b2201e93ab5e1"},{"url":"https://git.kernel.org/stable/c/fc069d00a0dbef40042fd681554d48dcd5a1d524"},{"url":"https://git.kernel.org/stable/c/13bfc94eef389bd664ffc67b00184919902c938a"},{"url":"https://git.kernel.org/stable/c/4400270ec0348d05dc0439d8f0130853ce7f9e20"}],"title":"s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm()","x_generator":{"engine":"bippy-1.2.0"}}}}