UBUNTU-CVE-2026-98473: Low severity ubuntu/linux-hwe-edge vulnerability

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: ~~~~~~~~~ APRESPONSEQNOTAVAIL not handled in vfioapmdevresetqueue() When the AP bus removes a queue device whose adapter or domain has been removed from the host's AP configuration, vfioapmdevremovequeue() is called. If the queue is still in the host's AP configuration at that point, it calls vfioapmdevresetqueue(), which issues a PQAP(ZAPQ). Since the adapter is already gone from the host configuration, apzapq() returns APRESPONSEQNOTAVAIL (0x01). This response code is not handled in vfioapmdevresetqueue()'s switch statement and falls through to the default case, which issues a WARN but does not call vfioapfreeaqicresources(). 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 APRESPONSEQNOTAVAIL to the same case as APRESPONSEDECONFIGURED and APRESPONSECHECKSTOPPED in vfioapmdevresetqueue(). Like those response codes, QNOTAVAIL 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: ~~~~~~~~~ APRESPONSEQNOTAVAIL not handled in apqstatuscheck() In vfioapmdevresetqueue(), there are four cases that indicate a queue reset has not yet completed, in which case apqresetcheck() 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 apqstatuscheck() to verify whether the reset has completed, failed or needs to be executed again. As described in Problem #1 above, apqresetcheck() does not specifically check for APRESPONSEQNOTAVAIL, thereby potentially leaking KVM GISC registration and the pinned guest page holding the NIB. This is fixed by adding a case statement for APRESPONSEQNOTAVAIL to apqstatuscheck() and returning -ENODEV for that case. The caller, apqresetcheck() will then check for this return code and call vfioapfreeaqicresources() to prevent the leak. Problem 3: ~~~~~~~~~ vfioapfreeaqicresources() leaks savedisc when kvm is NULL vfioapfreeaqicresources() guards the call to kvms390giscunregister() with: if (q->savedisc != VFIOAPISCINVALID && !WARNON(!(q->matrixmdev && q->matrixmdev->kvm))) If matrixmdev->kvm is NULL -- which can happen when vfioapmdevunsetkvm() has already run and cleared kvm before a subsequent cleanup path reaches this function -- the WARNON fires and the entire block is skipped. This leaves q->savedisc 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 kvms390giscunregister() need not and cannot be called; however, q->savedisc must always be cleared. Fix this by separating the kvms390giscunregister() call from the q->savedisc reset. The WARNON now guards only the genuinely impossible case of matrixmdev being NULL. A NULL kvm is handled gracefully by skipping only the unregister call, and q->savedisc = VFIOAPISCINVALID is set unconditionally whenever savedisc was not already invalid. Additionally, add an else clause to the host-config check in vfioapmdevremovequeue() to call vfioapfreeaqicresources() 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 vfioapmdevresetqueue ---truncated---