From: Anthony Krowiak <akrowiak@linux.ibm.com>
To: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org
Cc: jjherne@linux.ibm.com, borntraeger@de.ibm.com,
mjrosato@linux.ibm.com, pasic@linux.ibm.com, alex@shazbot.org,
kwankhede@nvidia.com, fiuczy@linux.ibm.com, pbonzini@redhat.com,
frankja@linux.ibm.com, imbrenda@linux.ibm.com,
agordeev@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com,
stable@vger.kernel.org
Subject: [PATCH v3 1/4] s390/vfio-ap: Fix leak of pinned NIB and registered NISC in vfio_ap_irq_enable/disable()
Date: Thu, 27 Aug 2026 09:24:27 -0400 [thread overview]
Message-ID: <20260827132441.555866-2-akrowiak@linux.ibm.com> (raw)
In-Reply-To: <20260827132441.555866-1-akrowiak@linux.ibm.com>
The vfio_ap_irq_enable() and vfio_ap_disable() functions execute the
PQAP(AQIC) instructions to enable/disable interrupts for an AP queue.
A switch statement is used to examine the status response code returned
from the instruction to determine whether it succeeded or failed and react
accordingly.
vfio_ap_irq_enable()
~~~~~~~~~~~~~~~~~~~~
For the default case, the vfio_ap_irq_disable function is invoked to
disable interrupts for the queue and clean up the AQIC resources (i.e.,
unpin the NIB and unregister the NISC). There are a number of problems
with this:
1. Neither the q->saved_iova nor q->saved_isc has been set, so the
AQIC resources - assuming those values have been previously set - will
be the NIB and NISC resources from a prior call; the NIB and NISC from
the current call are therefore leaked.
2. Interrupts may never have been enabled. Sending a disable instruction to
a queue that the hardware just told you is in a bad state (CHECKSTOPPED,
DECONFIGURED, Q_NOT_AVAIL) is at best wasted work and at worst generates
a further WARN_ONCE from inside vfio_ap_irq_disable's own default.
3. The hardware just rejected the new ap_aqic() enable attempt with an
unexpected status. Disabling a previously-working IRQ config - assuming
that is even possible - as a reaction to a failed enable attempt does
not make sense; it is actively destructive, tearing down something that
was working for no valid reason.
The fix is to unregister the NISC and an unpin the NIB in the default case
of the switch statement.
vfio_ap_irq_disable()
~~~~~~~~~~~~~~~~~~~~~
There are two problems with the way this function handles the response
code returned from the PQAP(AQIC) instruction:
1. For response codes AP_RESPONSE_NORMAL or AP_RESPONSE_OTHERWISE_CHANGED,
a call is made to vfio_ap_wait_for_irqclear() which waits for the IR
bit - indicates whether interrupts are enabled (1) or disabled (0) - to
be cleared. That function does not return anything, so there is no way
to determine whether it succeeded or not. The vfio_ap_irq_disable()
function then frees the AQIC resources. This is a problem because the
hardware may still write to the NIB resulting in a use-after-free kernel
crash.
The fix for this is to add a boolean return code from
vfio_ap_wait_for_irqclear(). This will be checked in
vfio_ap_irq_disable() and if clearing of the IR bit could not be
verified, the AQIC resources will be allowed to leak. This is
preferable to a kernel crash.
2. For response code AP_RESPONSE_INVALID_ADDRESS - indicates the NIB
address passed to PQAP(AQIC) is not valid - as well as the default case,
the vfio_ap_irq_disable() frees the AQIC resources. Since the AQIC
disable was rejected, the IRQ is still enabled and the hardware still
holds the NIB address, so freeing the NIB could result in a
use-after-free kernel crash.
The fix for this is to allow the AQIC resources to be leaked. This is
preferable to a kernel crash.
Fixes: ec89b55e3bce7 ("s390: ap: implement PAPQ AQIC interception in kernel")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
---
drivers/s390/crypto/vfio_ap_ops.c | 97 ++++++++++++++++++++++++-------
1 file changed, 77 insertions(+), 20 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index 940c0ff668be..64d6a8f8fa96 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -226,16 +226,24 @@ static struct vfio_ap_queue *vfio_ap_mdev_get_queue(
}
/**
- * vfio_ap_wait_for_irqclear - clears the IR bit or gives up after 5 tries
+ * vfio_ap_wait_for_irqclear:
+ * Waits for the IR bit to clear thus indicating IRQs are disabled for a queue
+ *
* @apqn: The AP Queue number
*
- * Checks the IRQ bit for the status of this APQN using ap_tapq.
- * Returns if the ap_tapq function succeeded and the bit is clear.
- * Returns if ap_tapq function failed with invalid, deconfigured or
- * checkstopped AP.
- * Otherwise retries up to 5 times after waiting 20ms.
+ * Repeatedly checks the IR bit for the status of a queue device by calling the
+ * PQAP(TAPQ) instruction every 20ms until: the IR bit is cleared; the response
+ * code from the PQAP instruction indicates the queue is not available or
+ * not operational; or the loop has executed more than 5 times.
+ *
+ * Return:
+ * - true if the bit is observed clear or the AP is non-operational (in which
+ * case no further interrupts can be generated)
+ *
+ * - false if the IR bit is still set after all retries are exhausted, meaning
+ * the hardware may still write to the NIB.
*/
-static void vfio_ap_wait_for_irqclear(int apqn)
+static bool vfio_ap_wait_for_irqclear(int apqn)
{
struct ap_queue_status status;
int retry = 5;
@@ -246,7 +254,7 @@ static void vfio_ap_wait_for_irqclear(int apqn)
case AP_RESPONSE_NORMAL:
case AP_RESPONSE_RESET_IN_PROGRESS:
if (!status.irq_enabled)
- return;
+ return true;
fallthrough;
case AP_RESPONSE_BUSY:
msleep(20);
@@ -257,12 +265,13 @@ static void vfio_ap_wait_for_irqclear(int apqn)
default:
WARN_ONCE(1, "%s: tapq rc %02x: %04x\n", __func__,
status.response_code, apqn);
- return;
+ return true;
}
} while (--retry);
- WARN_ONCE(1, "%s: tapq rc %02x: %04x could not clear IR bit\n",
- __func__, status.response_code, apqn);
+ WARN_ONCE(1, "%s: tapq rc %02x: timed out verifying interrupts disabled for %02x.%04x\n",
+ __func__, status.response_code, AP_QID_CARD(apqn), AP_QID_QUEUE(apqn));
+ return false;
}
/**
@@ -317,8 +326,21 @@ static struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q)
switch (status.response_code) {
case AP_RESPONSE_OTHERWISE_CHANGED:
case AP_RESPONSE_NORMAL:
- vfio_ap_wait_for_irqclear(q->apqn);
- goto end_free;
+ /*
+ * AQIC disable was accepted (NORMAL), or the queue was
+ * already disabled or a prior async request is still
+ * completing (OTHERWISE_CHANGED). In both cases, we must
+ * wait until interrupt processing has been disabled
+ * before proceeding.
+ *
+ * If it could not be determined whether interrupts
+ * have been disabled, do not free the AQIC resources: the
+ * hardware may still write to the NIB, so leave it pinned
+ * to avoid a use-after-free. The resources will be leaked.
+ */
+ if (vfio_ap_wait_for_irqclear(q->apqn))
+ goto end_free;
+ goto end_fail;
case AP_RESPONSE_RESET_IN_PROGRESS:
case AP_RESPONSE_BUSY:
msleep(20);
@@ -326,18 +348,46 @@ static struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q)
case AP_RESPONSE_Q_NOT_AVAIL:
case AP_RESPONSE_DECONFIGURED:
case AP_RESPONSE_CHECKSTOPPED:
+ /* AP not operational; no further interrupts possible */
+ WARN_ONCE(1, "%s: ap_aqic status %d\n", __func__,
+ status.response_code);
+ goto end_free;
case AP_RESPONSE_INVALID_ADDRESS:
default:
- /* All cases in default means AP not operational */
+ /*
+ * The AQIC disable was rejected; IRQ is still enabled
+ * and the hardware still holds the NIB address. Do not
+ * free resources.
+ */
WARN_ONCE(1, "%s: ap_aqic status %d\n", __func__,
status.response_code);
- goto end_free;
+ goto end_fail;
}
} while (retries--);
WARN_ONCE(1, "%s: ap_aqic status %d\n", __func__,
status.response_code);
+
+end_fail:
+ /*
+ * We are here either because of a failure to verify that
+ * interrupts have been disabled, or because the AQIC instruction
+ * failed to disable them. The AQIC resources - the pinned NIB page
+ * and the registered guest ISC - cannot be freed here. The hardware
+ * may still write to the NIB; freeing the pinned page would result
+ * in a use-after-free kernel crash. The resources will therefore be
+ * leaked. This is preferable to a use-after-free.
+ */
+ return status;
+
end_free:
+ /*
+ * This label is reached because the queue was successfully disabled,
+ * or because the queue is not operational, in which case interrupts
+ * can not be processed, so free the AQIC resources - the pinned NIB
+ * page and the registered guest ISC - used to enable interrupts
+ * so they will not be leaked.
+ */
vfio_ap_free_aqic_resources(q);
return status;
}
@@ -495,7 +545,12 @@ static struct ap_queue_status vfio_ap_irq_enable(struct vfio_ap_queue *q,
q->saved_isc = isc;
break;
case AP_RESPONSE_OTHERWISE_CHANGED:
- /* We could not modify IRQ settings: clear new configuration */
+ /*
+ * IRQ control is already set as requested or a prior async
+ * request has not yet completed; in either case, this response
+ * comes with CC=3 indicating the new NIB and ISC were not accepted by
+ * the hardware, so clean them up.
+ */
ret = kvm_s390_gisc_unregister(kvm, isc);
if (ret)
VFIO_AP_DBF_WARN("%s: kvm_s390_gisc_unregister: rc=%d isc=%d, apqn=%#04x\n",
@@ -503,9 +558,12 @@ static struct ap_queue_status vfio_ap_irq_enable(struct vfio_ap_queue *q,
vfio_unpin_pages(&q->matrix_mdev->vdev, nib, 1);
break;
default:
- pr_warn("%s: apqn %04x: response: %02x\n", __func__, q->apqn,
- status.response_code);
- vfio_ap_irq_disable(q);
+ /* We could not modify IRQ settings: clear new configuration */
+ ret = kvm_s390_gisc_unregister(kvm, isc);
+ if (ret)
+ VFIO_AP_DBF_WARN("%s: kvm_s390_gisc_unregister: rc=%d isc=%d, apqn=%#04x\n",
+ __func__, ret, isc, q->apqn);
+ vfio_unpin_pages(&q->matrix_mdev->vdev, nib, 1);
break;
}
@@ -635,7 +693,6 @@ static int handle_pqap(struct kvm_vcpu *vcpu)
}
status = vcpu->run->s.regs.gprs[1];
-
/* If IR bit(16) is set we enable the interrupt */
if ((status >> (63 - 16)) & 0x01)
qstatus = vfio_ap_irq_enable(q, status & 0x07, vcpu);
--
2.53.0
next prev parent reply other threads:[~2026-08-27 13:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 13:24 [PATCH v3 0/4] s390/vfio-ap: Fix pre-existing bugs in vfio_ap device driver Anthony Krowiak
2026-08-27 13:24 ` Anthony Krowiak [this message]
2026-08-27 13:39 ` [PATCH v3 1/4] s390/vfio-ap: Fix leak of pinned NIB and registered NISC in vfio_ap_irq_enable/disable() sashiko-bot
2026-08-28 20:14 ` Anthony Krowiak
2026-08-27 13:24 ` [PATCH v3 2/4] s390/vfio-ap: Fix failure to release IRQ notification eventfd contexts Anthony Krowiak
2026-08-27 13:32 ` sashiko-bot
2026-08-27 13:24 ` [PATCH v3 3/4] s390/vfio-ap: Fix unbounded loop in apq_reset_check() Anthony Krowiak
2026-08-27 13:43 ` sashiko-bot
2026-08-27 20:04 ` Anthony Krowiak
2026-08-27 13:24 ` [PATCH v3 4/4] s390/vfio-ap: Use AP_DOMAINS for adm_add bitmap size in vfio_ap_mdev_cfg_add() Anthony Krowiak
2026-08-27 13:30 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260827132441.555866-2-akrowiak@linux.ibm.com \
--to=akrowiak@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=alex@shazbot.org \
--cc=borntraeger@de.ibm.com \
--cc=fiuczy@linux.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=jjherne@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox