CVE-2026-98473

Source
https://cve.org/CVERecord?id=CVE-2026-98473
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-98473.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2026-98473
Downstream
Published
2026-10-18T15:15:35Z
Modified
2026-10-19T02:46:19Z
Summary
s390/vfio-ap: fix KVM GISC and page leak when queue removed from host config
Details

In the Linux kernel, the following vulnerability has been resolved:

s390/vfio-ap: fix KVM GISC and page leak when queue removed from host config

Three related problems exist in the handling of KVM interrupt and page resources when a queue is removed from the host's AP configuration while assigned to a mediated device (mdev).

Problem 1:

AP_RESPONSE_Q_NOT_AVAIL not handled in vfio_ap_mdev_reset_queue()

When the AP bus removes a queue device whose adapter or domain has
been removed from the host's AP configuration,
vfio_ap_mdev_remove_queue() is called. If the queue is still in the
host's AP configuration at that point, it calls
vfio_ap_mdev_reset_queue(), which issues a PQAP(ZAPQ). Since the
adapter is already gone from the host configuration, ap_zapq() returns
AP_RESPONSE_Q_NOT_AVAIL (0x01). This response code is not handled in
vfio_ap_mdev_reset_queue()'s switch statement and falls through to
the default case, which issues a WARN but does not call
vfio_ap_free_aqic_resources(). As a result, if IRQ handling was
enabled for the queue by the guest, the KVM GISC registration and
the pinned guest page holding the notification indicator byte (NIB)
are both leaked.

This is fixed by adding AP_RESPONSE_Q_NOT_AVAIL to the same case as
AP_RESPONSE_DECONFIGURED and AP_RESPONSE_CHECKSTOPPED in
vfio_ap_mdev_reset_queue(). Like those response codes, Q_NOT_AVAIL
indicates the queue is not operational and no further reset attempts
are possible; the correct action is to free the IRQ resources
immediately.

Problem 2:

AP_RESPONSE_Q_NOT_AVAIL not handled in apq_status_check()

In vfio_ap_mdev_reset_queue(), there are four cases that indicate a queue reset has not yet completed, in which case apq_reset_check() is queued to a work queue to verify completion of the reset operation. This function uses the PQAP(TAPQ) function to get the queue's status and calls apq_status_check() to verify whether the reset has completed, failed or needs to be executed again. As described in Problem #1 above, apq_reset_check() does not specifically check for AP_RESPONSE_Q_NOT_AVAIL, thereby potentially leaking KVM GISC registration and the pinned guest page holding the NIB.

This is fixed by adding a case statement for AP_RESPONSE_Q_NOT_AVAIL to apq_status_check() and returning -ENODEV for that case. The caller, apq_reset_check() will then check for this return code and call vfio_ap_free_aqic_resources() to prevent the leak.

Problem 3:

vfio_ap_free_aqic_resources() leaks saved_isc when kvm is NULL

vfio_ap_free_aqic_resources() guards the call to
kvm_s390_gisc_unregister() with:

    if (q->saved_isc != VFIO_AP_ISC_INVALID &&
        !WARN_ON(!(q->matrix_mdev && q->matrix_mdev->kvm)))

If matrix_mdev->kvm is NULL -- which can happen when
vfio_ap_mdev_unset_kvm() has already run and cleared kvm before a
subsequent cleanup path reaches this function -- the WARN_ON fires
and the entire block is skipped. This leaves q->saved_isc set to a
non-invalid value, creating a potential double-free on any subsequent
call to this function.

When kvm is NULL the KVM guest is already torn down, so
kvm_s390_gisc_unregister() need not and cannot be called; however,
q->saved_isc must always be cleared. Fix this by separating the
kvm_s390_gisc_unregister() call from the q->saved_isc reset. The
WARN_ON now guards only the genuinely impossible case of matrix_mdev
being NULL. A NULL kvm is handled gracefully by skipping only the
unregister call, and q->saved_isc = VFIO_AP_ISC_INVALID is set
unconditionally whenever saved_isc was not already invalid.

Additionally, add an else clause to the host-config check in
vfio_ap_mdev_remove_queue() to call vfio_ap_free_aqic_resources()
directly when the queue is not in the host's AP configuration. This
serves as a backstop: when the AP bus fires the driver .remove
callback after an adapter is removed from the host config, the queue
is by definition no longer addressable, so vfio_ap_mdev_reset_queue
---truncated---
Database specific
{
    "cna_assigner":  "Linux",
    "osv_generated_from":  "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/98xxx/CVE-2026-98473.json"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
b9bd10c43456d16abd97b717446f51afb3b88411
Fixed
da69d3ac53490724eba0ade9deb4e539a6ae9034
Fixed
cf441a0db681dfad5e89b015d6be11365159d7a9
Fixed
3c3433657c82f200dae36c29e2b80681c81b85be
Fixed
65e05ec252a9b79e75930d3c4dd42d8877db04c5
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
6.6.15
Fixed
6.7
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
6.7.3
Fixed
6.8
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
582014b08cb83383cdd61f052cd81e8aa5023696
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
7abe1494896c052d5dcf4ba910656777aff72fbb

Affected versions

v6.*
v6.6.100
v6.6.101
v6.6.102
v6.6.103
v6.6.104
v6.6.105
v6.6.106
v6.6.107
v6.6.108
v6.6.109
v6.6.110
v6.6.111
v6.6.112
v6.6.113
v6.6.114
v6.6.115
v6.6.116
v6.6.117
v6.6.118
v6.6.119
v6.6.120
v6.6.121
v6.6.122
v6.6.123
v6.6.124
v6.6.125
v6.6.126
v6.6.127
v6.6.128
v6.6.129
v6.6.130
v6.6.131
v6.6.132
v6.6.133
v6.6.134
v6.6.135
v6.6.136
v6.6.137
v6.6.138
v6.6.139
v6.6.140
v6.6.141
v6.6.142
v6.6.143
v6.6.144
v6.6.145
v6.6.146
v6.6.147
v6.6.148
v6.6.149
v6.6.15
v6.6.150
v6.6.151
v6.6.152
v6.6.153
v6.6.154
v6.6.155
v6.6.156
v6.6.157
v6.6.158
v6.6.159
v6.6.16
v6.6.17
v6.6.18
v6.6.19
v6.6.20
v6.6.21
v6.6.22
v6.6.23
v6.6.24
v6.6.25
v6.6.26
v6.6.27
v6.6.28
v6.6.29
v6.6.30
v6.6.31
v6.6.32
v6.6.33
v6.6.34
v6.6.35
v6.6.36
v6.6.37
v6.6.38
v6.6.39
v6.6.40
v6.6.41
v6.6.42
v6.6.43
v6.6.44
v6.6.45
v6.6.46
v6.6.47
v6.6.48
v6.6.49
v6.6.50
v6.6.51
v6.6.52
v6.6.53
v6.6.54
v6.6.55
v6.6.56
v6.6.57
v6.6.58
v6.6.59
v6.6.60
v6.6.61
v6.6.62
v6.6.63
v6.6.64
v6.6.65
v6.6.66
v6.6.67
v6.6.68
v6.6.69
v6.6.70
v6.6.71
v6.6.72
v6.6.73
v6.6.74
v6.6.75
v6.6.76
v6.6.77
v6.6.78
v6.6.79
v6.6.80
v6.6.81
v6.6.82
v6.6.83
v6.6.84
v6.6.85
v6.6.86
v6.6.87
v6.6.88
v6.6.89
v6.6.90
v6.6.91
v6.6.92
v6.6.93
v6.6.94
v6.6.95
v6.6.96
v6.6.97
v6.6.98
v6.6.99
v6.7.10
v6.7.11
v6.7.12
v6.7.3
v6.7.4
v6.7.5
v6.7.6
v6.7.7
v6.7.8
v6.7.9

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-98473.json"

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
6.8.0
Fixed
6.12.112
Type
ECOSYSTEM
Events
Introduced
6.13.0
Fixed
6.18.55
Type
ECOSYSTEM
Events
Introduced
6.19.0
Fixed
7.2.9

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-98473.json"