{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-89960",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-89960"
  ],
  "published": "2026-09-16T10:32:03Z",
  "summary": "s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm()",
  "details": "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.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.1.47-1+rpt4"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-2712",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v6",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v8",
            "binary_version": "1:6.1.47-1+rpt4"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.47-1+rpt4": {
            "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e",
            "upstream_version": "6.1.47",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": null,
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-89960"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/eb6cc898501a004c0fa8aab951351d9c959b91cc"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/6a180adafc2a8a5fbe815985c71b2201e93ab5e1"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/fc069d00a0dbef40042fd681554d48dcd5a1d524"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/13bfc94eef389bd664ffc67b00184919902c938a"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/4400270ec0348d05dc0439d8f0130853ce7f9e20"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-09-16T14:40:32Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 8.8,
      "cvss_v3_severity": "High",
      "scenario": "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."
    }
  }
}