[CVE-2026-89960][MODERATE 7.0] s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm()

[AL-KERNEL <alkernel@kernelcve.org>]

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 <mjrosato@linux.ibm.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260806173435.105044-1-akrowiak@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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).