[PATCH] s390/vfio-ap: Fix leak of KVM GISC resources

[PATCH] s390/vfio-ap: Fix leak of KVM GISC resources

[Anthony Krowiak]

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

Two 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: 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()
would always return Q_NOT_AVAIL. The else clause handles this case
directly without the unnecessary ap_zapq() call, and ensures cleanup
occurs even if kvm has already been set to NULL by a prior call to
vfio_ap_mdev_unset_kvm().

Fixes: b9bd10c43456d ("s390/vfio-ap: do not reset queue removed from host config")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
---
 drivers/s390/crypto/vfio_ap_ops.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index 44b3a1dcc1b3..e277062e92be 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -270,9 +270,9 @@ static void vfio_ap_free_aqic_resources(struct vfio_ap_queue *q)
 {
 	if (!q)
 		return;
-	if (q->saved_isc != VFIO_AP_ISC_INVALID &&
-	    !WARN_ON(!(q->matrix_mdev && q->matrix_mdev->kvm))) {
-		kvm_s390_gisc_unregister(q->matrix_mdev->kvm, q->saved_isc);
+	if (q->saved_isc != VFIO_AP_ISC_INVALID) {
+		if (!WARN_ON(!q->matrix_mdev) && q->matrix_mdev->kvm)
+			kvm_s390_gisc_unregister(q->matrix_mdev->kvm, q->saved_isc);
 		q->saved_isc = VFIO_AP_ISC_INVALID;
 	}
 	if (q->saved_iova && !WARN_ON(!q->matrix_mdev)) {
@@ -2004,6 +2004,7 @@ static void vfio_ap_mdev_reset_queue(struct vfio_ap_queue *q)
 		break;
 	case AP_RESPONSE_DECONFIGURED:
 	case AP_RESPONSE_CHECKSTOPPED:
+	case AP_RESPONSE_Q_NOT_AVAIL:
 		vfio_ap_free_aqic_resources(q);
 		break;
 	default:
@@ -2499,12 +2500,15 @@ void vfio_ap_mdev_remove_queue(struct ap_device *apdev)
 	/*
 	 * If the queue is not in the host's AP configuration, then resetting
 	 * it will fail with response code 01, (APQN not valid); so, let's make
-	 * sure it is in the host's config.
+	 * sure it is in the host's config. If it is not, free the KVM GISC
+	 * resources.
 	 */
 	if (test_bit_inv(apid, (unsigned long *)matrix_dev->info.apm) &&
 	    test_bit_inv(apqi, (unsigned long *)matrix_dev->info.aqm)) {
 		vfio_ap_mdev_reset_queue(q);
 		flush_work(&q->reset_work);
+	} else {
+		vfio_ap_free_aqic_resources(q);
 	}
 
 done:
-- 
2.53.0

Re: [PATCH] s390/vfio-ap: Fix leak of KVM GISC resources

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Use-After-Free of `q->matrix_mdev` due to dangling pointer left after unassigning an adapter or domain for a queue not present in shadow_apcb.
- [High] The patch fixes KVM GISC and NIB page leaks when a queue is synchronously reset by handling AP_RESPONSE_Q_NOT_AVAIL, but it misses the asynchronous reset polling path, leading to the same resource leaks.
- [High] The apq_reset_check workqueue function loops indefinitely without a timeout while waiting for an AP queue reset to complete, causing a KVM process deadlock if hardware fails.
--

--- Patch [1]: [PATCH] s390/vfio-ap: Fix leak of KVM GISC resources ---
commit c19d4565d7b440cb8eddb06c5a8a375c867d24ea
Author: Anthony Krowiak <akrowiak@linux.ibm.com>

s390/vfio-ap: Fix leak of KVM GISC resources

Two 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). This patch addresses the
AP_RESPONSE_Q_NOT_AVAIL response from ap_zapq() and fixes the
vfio_ap_free_aqic_resources() cleanup.

> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index 44b3a1dcc1b36..e277062e92bea 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
[ ... ]
> @@ -2004,6 +2004,7 @@ static void vfio_ap_mdev_reset_queue(struct vfio_ap_queue *q)
>  		break;
>  	case AP_RESPONSE_DECONFIGURED:
>  	case AP_RESPONSE_CHECKSTOPPED:
> +	case AP_RESPONSE_Q_NOT_AVAIL:
>  		vfio_ap_free_aqic_resources(q);
>  		break;
>  	default:

[Severity: High]
This isn't a bug introduced by this patch, but does the same resource leak
happen when the asynchronous polling path in apq_reset_check() encounters an
AP_RESPONSE_Q_NOT_AVAIL response?

When an adapter or domain is removed from the host config while a reset is
asynchronously polling, ap_tapq() can return AP_RESPONSE_Q_NOT_AVAIL. The
helper apq_status_check() falls through to its default case and returns -EIO:

drivers/s390/crypto/vfio_ap_ops.c:apq_status_check() {
    ...
    default:
        WARN(true,
             "failed to verify reset of queue %02x.%04x: TAPQ rc=%u\n",
             AP_QID_CARD(apqn), AP_QID_QUEUE(apqn),
             status->response_code);
        return -EIO;
}

This causes apq_reset_check() to exit immediately, skipping the cleanup:

drivers/s390/crypto/vfio_ap_ops.c:apq_reset_check() {
    ...
        ret = apq_status_check(q->apqn, &status);
        if (ret == -EIO)
            return;
    ...
}

Does the default case in vfio_ap_mdev_reset_queue() also need to call
vfio_ap_free_aqic_resources() to prevent a leak on an unhandled ZAPQ
response?

>  		WARN(true,
>  		     "PQAP/ZAPQ for %02x.%04x failed with invalid rc=%u\n",
>  		     AP_QID_CARD(q->apqn), AP_QID_QUEUE(q->apqn),
>  		     status.response_code);
>  	}
>  }
[ ... ]

[Severity: Critical]
This is a pre-existing issue, but is there a use-after-free of q->matrix_mdev
if an adapter is unassigned that is not passed through to a guest?

If an adapter is unassigned, its bit is cleared from matrix.apm and
vfio_ap_mdev_unlink_adapter() removes the queue from the mdev's hash table.
However, if the queue's bit is not set in shadow_apcb, it is skipped from
qlist:

drivers/s390/crypto/vfio_ap_ops.c:vfio_ap_mdev_unlink_adapter() {
    ...
        if (q && qlist) {
            if (test_bit_inv(apid, matrix_mdev->shadow_apcb.apm) &&
                test_bit_inv(apqi, matrix_mdev->shadow_apcb.aqm))
                list_add_tail(&q->reset_qnode, qlist);
        }
    ...
}

Because it is missing from qlist, vfio_ap_mdev_hot_unplug_adapters() skips
calling vfio_ap_unlink_mdev_fr_queue(q):

drivers/s390/crypto/vfio_ap_ops.c:vfio_ap_mdev_hot_unplug_adapters() {
    ...
    list_for_each_entry_safe(q, tmpq, &qlist, reset_qnode) {
        vfio_ap_unlink_mdev_fr_queue(q);
        list_del(&q->reset_qnode);
    }
}

This leaves q->matrix_mdev dangling. Later, when the AP bus queue device is
removed, get_update_locks_for_queue() dereferences the freed pointer:

drivers/s390/crypto/vfio_ap_ops.c:get_update_locks_for_queue() {
    ...
    if (q->matrix_mdev && q->matrix_mdev->kvm)
        mutex_lock(&q->matrix_mdev->kvm->lock);
    ...
}

Can this lead to a kernel panic during normal operational reconfiguration?


[Severity: High]
This is a pre-existing issue, but will apq_reset_check() poll indefinitely
without a timeout if the hardware wedges?

drivers/s390/crypto/vfio_ap_ops.c:apq_reset_check() {
    ...
    while (true) {
        msleep(AP_RESET_INTERVAL);
        elapsed += AP_RESET_INTERVAL;
        status = ap_tapq(q->apqn, NULL);
        ret = apq_status_check(q->apqn, &status);
        if (ret == -EIO)
            return;
        if (ret == -EBUSY) {
            pr_notice_ratelimited(...);
        } else {
            ...
            if (q->reset_status.response_code == AP_RESPONSE_RESET_IN_PROGRESS ||
                ...
                ret == -EAGAIN) {
                status = ap_zapq(q->apqn, 0);
                ...
                continue;
            }
            ...
            break;
        }
    }
}

Operations like vfio_ap_mdev_reset_queues() schedule this work and synchronously
wait for it while holding global locks:

drivers/s390/crypto/vfio_ap_ops.c:vfio_ap_mdev_reset_queues() {
    ...
    hash_for_each(matrix_mdev->qtable.queues, loop_cursor, q, mdev_qnode) {
        flush_work(&q->reset_work);

        if (q->reset_status.response_code)
            ret = -EIO;
    }
    ...
}

If the queue is stuck in hardware and continuously returns AP_RESPONSE_BUSY or
AP_RESPONSE_RESET_IN_PROGRESS, will this permanently block the locks and
deadlock the host driver and KVM process?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260818115819.1656595-1-akrowiak@linux.ibm.com?part=1

Re: [PATCH] s390/vfio-ap: Fix leak of KVM GISC resources

[Matthew Rosato]

On 8/18/26 7:58 AM, Anthony Krowiak wrote:
> s390/vfio-ap: fix KVM GISC and page leak when queue removed from host config
> 
> Two 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: 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()
> would always return Q_NOT_AVAIL. The else clause handles this case
> directly without the unnecessary ap_zapq() call, and ensures cleanup
> occurs even if kvm has already been set to NULL by a prior call to
> vfio_ap_mdev_unset_kvm().
> 
> Fixes: b9bd10c43456d ("s390/vfio-ap: do not reset queue removed from host config")
> Cc: stable@vger.kernel.org
> Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
> ---

Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>

For archive purposes, this is a continuation of 

[PATCH v5 9/9] s390/vfio-ap: Fix memory leak when queue removed from host AP config

https://lore.kernel.org/linux-s390/20260812200240.818004-10-akrowiak@linux.ibm.com/