From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-89960][MODERATE 7.0] s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm() Date: Wed, 16 Sep 2026 07:32:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-89960 X-AL-KERNEL-Priority: MODERATE 7.0 X-AL-KERNEL-Severity: MODERATE 7.0 X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: YES X-AL-KERNEL-ActionableScore: 6 X-AL-KERNEL-ActionableScore-Lower: 5 X-AL-KERNEL-Commit: eb6cc898501a004c0fa8aab951351d9c959b91cc List-Id: CVE: CVE-2026-89960 Priority: MODERATE 7.0 AL-KERNEL base severity: MODERATE KPANIC flag: YES Patch: s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm() Commit: eb6cc898501a004c0fa8aab951351d9c959b91cc Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=eb6cc898501a004c0fa8aab951351d9c959b91cc Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89960 Analysis date: Wed, 16 Sep 2026 07:32:15 -0400 ActionableScore: 6 ActionableScore lower bound: 5 Actionable bucket: Actionable Moderate / Strong Important candidate requiring manual review Manual review required: YES Summary: No one-sentence report phrase was found. ====================================================================== ABOUT THIS REPORT ====================================================================== The original Linux kernel CVE announcement for CVE-2026-89960 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89960 The original announcement does not normally provide a security severity estimate, CVSS assessment, or enough information to determine whether the reported kernel bug represents a practically relevant security issue. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. It combines an autonomous classifier with LLM-assisted technical analysis and a separate ActionableScore mechanism. The purpose of this report is to prioritize Linux kernel CVEs before manual review, identify cases that require prompt investigation, and support automatic closure of issues that are unlikely to have meaningful security impact. Published priority for this report: MODERATE 7.0 Manual review required: YES A detailed explanation of the methodology and priority rules is included at the end of this message. ====================================================================== AL-KERNEL CLASSIFICATION RESULT ====================================================================== CVE-2026-89960 MODERATE https://www.kernelcve.org/list/?q=CVE-2026-89960 CHECK WITH IMPACT FROM ORIG NN MODERATE Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H';*CWE-416;CWE-362;*CWE-672;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7';DESCR 'A stale pointer use-after-free can occur in the s390 vfio-ap KVM path because kvm arch crypto pqap_hook may be left pointing to a failing matrix mdev after vfio_ap_mdev_set_kvm returns an error for a conflicting KVM assignment. If that matrix mdev is later closed and freed, a guest PQAP instruction can dereference the stale hook through pqap_hook_rwsem and access freed host kernel memory. For the CVSS the PR:L is used because reliable triggering requires a local user or management process with access to KVM VFIO mdev assignment or equivalent delegated virtualization control, but not necessarily full host root in practical risk terms. The issue is not directly network reachable and depends on s390 KVM with vfio-ap mediated device usage. Impact is at least local denial of service via host kernel crash and in worst case may allow confidentiality or integrity impact because the primitive is a stale pointer UAF in host kernel code.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 6) YES LOCK DEADLOCK RACE ERRORPATH UAF HARDWARE LINUS KPANIC KPANIC INCREASED_TO_HIGH_BASED_ON_GUESSCVSS DECREASED_TO_MODERATE7_BASED_ON_FALSEPOSCHECKOFDH NO NO checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=6 ActionableScoreLower=5 PrimitiveClass=CLASS_B RealUAF=YES HostAdminRequired=UNKNOWN NamespaceScopedPrivilege=NO ImportantCandidate=YES ManualReview=REQUIRED AutoDowngradeAllowed=NO 1. ActionableScore * Raw conservative score: 5 * Conservative score: 5. No floor or cap changed the score. * Raw paranoid score: 6 * Paranoid score: 6. No floor or cap changed the score. * Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**:: 2. Signal breakdown Conservative positive signals: * +2 Real UAF / lifetime violation. The commit directly establishes that kvm->arch.crypto.pqap_hook can remain pointing to matrix_mdev->pqap_hook after the failing matrix_mdev is later closed and freed. * +1 Reliable host kernel crash / strong DoS. A later guest PQAP instruction can dereference the stale hook and fault in host kernel context. * +1 KVM/VFIO security-boundary relevance. The stale host kernel pointer is consumed from the KVM guest PQAP intercept path, so the demonstrated effect crosses from guest execution into host kernel processing, even though this alone is not strong guest-to-host exploitation leverage. * +1 Attacker-influenced active-object lifetime sequence. A local VMM/VFIO management actor can plausibly drive the conflicting mdev assignment failure, later close/free the failing mdev, and run or control the guest that executes PQAP. Paranoid additional signal: * +1 Weak exploitation concern. The stale pointer is not a fixed passive buffer. It is an active structured hook in KVM s390 crypto state and is later consumed by the PQAP intercept path. This supports unresolved exploitation-leverage review, but not CLASS_A. Important non-awarded signals: * +2 Strong LPE / strong exploitation leverage not awarded. Controlled reclaim, attacker-shaped replacement contents, arbitrary host read/write, callback control, or demonstrated guest-to-host escape are not established. * Concrete repeated release/refcount signal not awarded. The bug is a stale hook dereference UAF, not a visible second put/release/refcount mutation on the exact same dangling reference. * Paranoid repeated-refcount leverage not awarded. No concrete stale refcount/lifetime mutation is shown. * Extra Availability not awarded. The host crash is already counted once. * Confidentiality and Integrity bonuses not awarded in the ActionableScore arithmetic. They remain worst-case CVSS concerns from a host-kernel UAF, but no concrete disclosure or unauthorized modification primitive is demonstrated. * Race/timing penalty not applied. The main vulnerable sequence is an ordered error path plus later close/free plus PQAP use, not a proven narrow externally uncontrollable race. * Rare hardware penalty not applied. s390 vfio-ap is specialized, but the patch is specifically for that deployment and the prompt requires concrete restrictive evidence before using niche configuration as a negative score. Repeated-release/refcount checklist: * First release can end lifetime: not applicable to the scored primitive. * Exact same reference survives to a second lifetime mutation: not established. * Second operation is a real lifetime/refcount mutation: not established. * +1 Concrete repeated release/refcount awarded: no. * Paranoid repeated-refcount +1 awarded: no. * FLOOR 5 applied: no. Conservative score already reaches 5. 3. Reachability analysis The evaluated attacker model is primarily a local VMM or virtualization-management actor with access to KVM/VFIO mdev assignment operations, plus the ability to cause or run guest code that executes PQAP. The patch does not establish a pure guest-only trigger because the stale pointer is created through host-side vfio-ap mdev set_kvm error handling and mdev close/free behavior. Host-admin-equivalent privilege is not positively established from the supplied evidence, because VFIO device access and VM operation can be delegated to a non-root VMM process in some deployments. However, below-host-admin reachability for the complete chain is also not fully proven by the patch alone, so HostAdminRequired is UNKNOWN rather than NO. NamespaceScopedPrivilege is NO. This path is s390 KVM/VFIO AP mediated-device handling, not an attacker-created user or network namespace path. Prior host setup is likely needed in practice: vfio-ap must be enabled, AP crypto resources must exist, and a mediated device must be available to a VM or VMM. This limits exposure but does not remove the established UAF once such a deployment exists. Special hardware exists: s390 AP crypto virtualization. This is an exposure qualifier, but not enough here to automatically downgrade a concrete host-kernel UAF to ordinary Moderate. Race repeatability is not the main limiting factor. The commit mentions locking and a potential race condition, but the stale pointer scenario is explained through a concrete error path where pqap_hook is set before conflict detection and not restored. KVM attacker-role split: * Malicious guest: can execute PQAP and trigger the stale dereference after the host-side stale hook exists. * Local VMM / /dev/kvm or VFIO process: controls the relevant mdev assignment and lifecycle operations. * Host administrator: may be needed for provisioning vfio-ap resources, but the supplied evidence does not prove host admin is required for the complete trigger in all deployments. * Trigger model: compound VMM/local-host setup plus guest PQAP execution, unless a deployment gives one actor control of both stages. 4. Primitive and severity interpretation The exact primitive is a stale pointer use-after-free in host KVM s390 crypto state. kvm->arch.crypto.pqap_hook may point into a matrix_mdev that failed attachment and was never recorded as matrix_mdev->kvm. Because unset_kvm will not clear the hook for that failed mdev, later free of matrix_mdev can leave kvm->arch.crypto.pqap_hook dangling. This is an active structured object UAF, not fixed stale storage. The stale pointer is consumed by guest PQAP handling through pqap_hook_rwsem, which is broader than a simple cleanup-only destructor fault. There is no concrete repeated release/refcount operation. This is category A ordinary stale dereference/use of a freed structured object, not category B second lifetime/refcount mutation through a dangling reference. PrimitiveClass is CLASS_B. A real host-kernel UAF is directly established, but controlled reclaim, arbitrary read/write, callback hijack, refcount takeover, or demonstrated privilege escalation is not established. Demonstrated consequence is host kernel crash / DoS. Speculative consequence is stronger memory-corruption exploitation from the stale structured hook, but the patch does not prove a usable exploit primitive beyond the UAF. ImportantCandidate is YES because the bug is a real active-object UAF in KVM/VFIO host state reachable through a virtualization path, and meaningful exploitation leverage beyond crash remains unresolved. AutoDowngradeAllowed is NO because automatically closing this as ordinary Moderate would discard a concrete host-kernel lifetime primitive across a virtualization boundary. This does not prove Important severity, but it requires manual review. Likely operational severity is actionable Moderate at minimum, with Strong Important candidacy depending on whether reviewers can establish below-host-admin reachability, controlled reclaim, useful stale field consumption, or a stronger guest-to-host primitive. 5. One-sentence report phrase A stale pqap_hook pointer in s390 vfio-ap can remain in KVM host crypto state after a failed mdev assignment, allowing a later guest PQAP instruction to dereference freed host kernel memory and cause at least a host DoS with unresolved UAF exploitation leverage. 6. Manual review recommendation MANUAL CHECK REQUIRED Reason: this is a concrete host-kernel UAF in a KVM/VFIO path, not a pure resource leak or warning-only bug. Strong exploitation is not proven, but automatic downgrade is unsafe because the stale active hook is later consumed from guest-triggered host kernel processing. 7. Call-site confidence Call-site confidence: high ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm() Commit: eb6cc898501a004c0fa8aab951351d9c959b91cc Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=eb6cc898501a004c0fa8aab951351d9c959b91cc Commit description: 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. Fixes: 86956e7 ("s390/vfio-ap: replace open coded locks for VFIO_GROUP_NOTIFY_SET_KVM notification") Cc: stable@vger.kernel.org Co-developed-by: Matthew Rosato Signed-off-by: Matthew Rosato Signed-off-by: Anthony Krowiak Acked-by: Christian Borntraeger Signed-off-by: Claudio Imbrenda Message-ID: <20260806173435.105044-1-akrowiak@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman Changed files: drivers/s390/crypto/vfio_ap_ops.c Diff excerpt: Not included in this email. See the upstream URL for the full patch. Full patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=eb6cc898501a004c0fa8aab951351d9c959b91cc ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-89960 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89960 The original CVE announcement normally does not include a security-level estimate. In particular, it may not contain a CVSS assessment, an impact level, or enough information to determine whether the reported bug is a practically relevant security issue. One purpose of this parallel CVE list is to provide that missing technical and prioritization information. The original goal of the AL-KERNEL project was to prioritize Linux kernel CVE analysis automatically before manual review. The system can also help identify non-security issues that may be suitable for automatic closure. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. The first analysis stage combines an autonomous classifier with additional LLM-based analysis. The autonomous classifier runs locally on a CPU and is based on a backpropagation neural network. Together, these mechanisms produce a technical vulnerability description, identify likely weakness types, estimate CVSS severity, and provide input for ActionableScore. Two CVSS estimates are retained because incomplete kernel vulnerability information often permits more than one defensible interpretation: Conservative CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H The Best / paranoid CVSS score: 7 The conservative vector represents a lower-impact interpretation. The Best/paranoid vector intentionally represents a plausible upper-bound interpretation and should not automatically be treated as demonstrated real-world impact. CVSS may also need to be adjusted for a particular Linux deployment, because actual reachability, privileges, enabled kernel configuration, hardware, namespaces, exposed device nodes, and other environmental conditions can differ significantly between systems. A separate ActionableScore mechanism evaluates practical remediation urgency. Its analysis may include reachability, attack prerequisites, subsystem exposure, memory-corruption characteristics, denial-of-service reliability, and possible confidentiality, integrity, or privilege-escalation impact. Conservative ActionableScore: 5 Paranoid ActionableScore: 6 The final base severity is taken directly from the second tab-separated field of the AL-KERNEL classification result. ActionableScore does not replace or independently override that final AL-KERNEL decision, and if ActionableScore adjusted impact level of ALKERNEL, then you would see self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7. For an AL-KERNEL result of MODERATE, this report uses the following additional presentation split: ActionableScore below 5 -> MODERATE REGULAR ActionableScore 5 or more -> MODERATE 7.0 The distinction between MODERATE REGULAR and MODERATE 7.0 makes it possible to identify Moderate issues that should receive manual analysis and fixes before lower-priority MODERATE REGULAR issues. In many cases, MODERATE REGULAR fixes may wait for a later rebase or routine update. There is one override in which MODERATE REGULAR becomes MODERATE 7.0 even when the ActionableScore is below 5. When the AL-KERNEL result contains the KPANIC flag, a MODERATE result is always presented as MODERATE 7.0. The KPANIC flag selected with few regexps without usage of AI at all, so it helps to detect cases when Kernel Crash happens and similar (to filter False-Negative results from the LLM usage). KPANIC indicates that a reliable kernel crash, kernel panic, or similarly serious kernel availability impact was identified by the classification workflow. AL-KERNEL base severity for this report: MODERATE KPANIC detected for this report: YES Published priority for this report (same as in Subject): MODERATE 7.0 These results are intended to support engineering triage. They are machine-generated estimates, and cases marked for manual review should be validated by a human security engineer before final disposition. For more info read docs linked from here: https://kernelcve.org/ (and you can submit you own patch there to generate such a report for non-existant CVE-id yet). Note that in many cases this AI tool selects higher severity, than real is (means you can expect Importants instead of Moderate 7.0 or Moderates 7.0 instead of regular Moderates). If you see such cases, please use reply email interface to add additional manual analyses info to this particular CVE. And please, please, let me know when you see Lows instead of Importants or Important instead of Low (because particular for such cases I need to tune this AI tool to make it better for this one and next similar). My contact email for such notifications is alexanjelausa@gmail.com (and both send reply to CVE record itself too and see "reply" button below for howto reply).