Linux Kernel CVE-2026-89960

Requires an s390/IBM Z host running KVM with vfio-ap AP crypto passthrough enabled, and local privileged access to create and attach vfio-ap mediated devices to a KVM guest (device-node/config control). The specific trigger is attaching a second matrix_mdev to a KVM instance that already owns a conflicting mdev, causing vfio_ap_mdev_set_kvm() to return -EPERM and leave a stale pqap_hook pointer; the use-after-free only materializes if that matrix_mdev is subsequently freed and the guest then executes a PQAP instruction. Limiting factors: not remotely reachable (AV:L), needs host-side privilege to configure mdevs, applies only to the niche s390 vfio-ap path, and depends on error-path plus free-then-execute sequencing rather than a single deterministic step.

This is a CWE-416 use-after-free in the s390 vfio-ap (AP crypto passthrough) driver, disclosed by the Linux kernel team with a patch already available. The vendor CVSS of 8.8 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) materially over-states real-world risk. The exploitation surface is not remote and not trivially reachable: an actor must have host-side privilege to create/configure a vfio-ap mediated device and attach it to a KVM instance, and the flawed error path only triggers when a SECOND mdev is bound to a KVM that already owns one. The actual harmful outcome is a stale pqap_hook pointer that, only if the failing matrix_mdev is later freed, is dereferenced when the guest executes a PQAP instruction - a use-after-free whose dominant impact is a host kernel crash (DoS), not the C:H/I:H confidentiality/integrity loss the vendor vector claims. There is no EPSS score, no CISA KEV listing, and no public POC in the provided data, so exploitation is theoretical. AC:L is questionable: reaching the free-then-deref window is a sequencing/timing-dependent condition, better modeled as AC:H. Net: a legitimately fixed hardening bug, but a low operational priority given the niche platform, the required local privilege, and the DoS-dominant impact. NOTE: the input Tag 'Information Disclosure' conflicts with the description, which is a use-after-free/DoS with no data-leak primitive described - treat the tag as mislabeled.

On an IBM Z host running KVM with AP crypto passthrough, a local privileged user configures a vfio-ap mediated device and attaches it to a KVM instance that already has a conflicting mdev, causing vfio_ap_mdev_set_kvm() to return -EPERM while leaving kvm->arch.crypto.pqap_hook pointing at the failing matrix_mdev. After that matrix_mdev is freed, a guest executing any PQAP instruction dereferences the stale hook pointer, producing a use-after-free and likely a host kernel panic. No public exploit code is identified at time of analysis, and successful triggering depends on the free-then-execute sequencing.