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,
freude@linux.ibm.com, stable@vger.kernel.org
Subject: [PATCH v8 3/6] s390/vfio-ap: Fix unbounded loop in apq_reset_check()
Date: Fri, 25 Sep 2026 08:45:48 -0400 [thread overview]
Message-ID: <20260925124551.665448-4-akrowiak@linux.ibm.com> (raw)
In-Reply-To: <20260925124551.665448-1-akrowiak@linux.ibm.com>
s390/vfio-ap: Fix unbounded loop in apq_reset_check()
The apq_reset_check() worker polls ap_tapq() in a while(true)
loop waiting for a queue reset to complete. When ap_tapq()
returns AP_RESPONSE_BUSY, AP_RESPONSE_RESET_IN_PROGRESS, or
AP_RESPONSE_BUSY, apq_status_check() returns -EBUSY and the
loop continues after sleeping AP_RESET_INTERVAL (20ms). There
is no upper bound on how many times the loop iterates, so if the
hardware continuously returns a busy response the worker runs
indefinitely.
This is particularly harmful because several callers of
vfio_ap_mdev_reset_queue() - such as vfio_ap_mdev_reset_queues(),
vfio_ap_mdev_reset_qlist() and vfio_ap_mdev_remove_queue() -
call flush_work() on the queue's reset_work while holding one
or more of the global matrix_dev locks (guests_lock,
mdevs_lock) or the KVM lock. An indefinitely spinning worker
permanently blocks access to all ap_matrix_mdev objects, which
could hang other guests that are using them.
Fix this by introducing AP_RESET_MAX_WAIT (2000ms) and breaking
out of the poll loop when elapsed time reaches that threshold.
If apq_reset_check() times out before verifying completion of
the reset, the AQIC resources associated with the queue cannot
be freed. The NIB is the active DMA target for AP interrupt
delivery until the reset completes; freeing the pinned page
would allow it to be reallocated to a new owner. A subsequent
hardware wild DMA-write to that physical address would corrupt the
new owner's memory and could crash or compromise the host kernel.
If the reset eventually completes, interrupts will be
terminated, but the pinned NIB page and ISC registration will
be leaked. This is preferable to a compromised kernel or kernel
crash, or waiting indefinitely and blocking access to all
mdevs, hanging the guests to which they are attached.
On timeout, q->reset_status.response_code is set to
AP_RESPONSE_RESET_IN_PROGRESS. This is used internally to
signal that the reset did not complete, and ensures that if
the queue is reset again, the re-issue logic in
apq_reset_check() will re-issue the ZAPQ.
This patch also fixes a bug whereby AP_RESPONSE_NORMAL (0)
returned from PQAP(ZAPQ) was incorrectly treated as
confirmation that the queue was zeroized. AP_RESPONSE_NORMAL
only indicates that the ZAPQ was accepted; zeroization is
performed asynchronously. To confirm completion, the following
bits in the status word returned from PQAP(TAPQ) must all
be verified:
status->irq_enabled == 0
status->queue_empty == 1
status->replies_waiting == 0
status->async == 0
Fixes: dd174833e44e ("s390/vfio-ap: remove upper limit on wait for queue reset to complete")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
---
drivers/s390/crypto/vfio_ap_ops.c | 134 ++++++++++++++++++++++++++----
1 file changed, 118 insertions(+), 16 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index cbe2fb564a7e..47d4936fb9d7 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -2123,6 +2123,12 @@ static int apq_status_check(int apqn, struct ap_queue_status *status)
return -EBUSY;
case AP_RESPONSE_BUSY:
+ /*
+ * The queue is busy with something unrelated to a reset and our
+ * ZAPQ was rejected outright. Re-issue the ZAPQ.
+ */
+ return -EAGAIN;
+
case AP_RESPONSE_ASSOC_SECRET_NOT_UNIQUE:
case AP_RESPONSE_ASSOC_FAILED:
/*
@@ -2148,8 +2154,59 @@ static int apq_status_check(int apqn, struct ap_queue_status *status)
}
}
+static void report_aqic_resource_leak(struct vfio_ap_queue *q)
+{
+ if (q->saved_isc != VFIO_AP_ISC_INVALID || q->saved_iova) {
+ if (q->matrix_mdev) {
+ dev_warn_ratelimited(mdev_dev(q->matrix_mdev->mdev),
+ "Reset timed out for APQN %02x.%04x: leaking AQIC resources (NIB page & GISC) to prevent host crash\n",
+ AP_QID_CARD(q->apqn),
+ AP_QID_QUEUE(q->apqn));
+ } else {
+ pr_warn_ratelimited("Reset timed out for APQN %02x.%04x: leaking AQIC resources (NIB page & GISC) to prevent host crash\n",
+ AP_QID_CARD(q->apqn),
+ AP_QID_QUEUE(q->apqn));
+ }
+ } else {
+ if (q->matrix_mdev) {
+ dev_warn_ratelimited(mdev_dev(q->matrix_mdev->mdev),
+ "Reset timed out for APQN %02x.%04x\n",
+ AP_QID_CARD(q->apqn),
+ AP_QID_QUEUE(q->apqn));
+ } else {
+ pr_warn_ratelimited("Reset timed out for APQN %02x.%04x\n",
+ AP_QID_CARD(q->apqn),
+ AP_QID_QUEUE(q->apqn));
+ }
+ }
+}
+
#define WAIT_MSG "Waited %dms for reset of queue %02x.%04x (%u, %u, %u)"
+/**
+ * apq_reset_finalize - store final TAPQ status and free AQIC resources.
+ * @q: the vfio_ap_queue
+ * @status: the final AP queue status returned by PQAP(TAPQ)
+ * @ret: the return value from apq_status_check()
+ *
+ * Copies the full TAPQ status word to q->reset_status so that all status
+ * bits reflect the confirmed end state of the queue. If ret == 0,
+ * zeroization was confirmed and the response code is overridden with
+ * AP_RESPONSE_NORMAL so that _queue_passable() returns true. For
+ * ret == -ENODEV (DECONFIGURED or CHECKSTOPPED), the non-zero response
+ * code is left intact so _queue_passable() correctly returns false.
+ * AQIC resources are then freed.
+ */
+static void apq_reset_finalize(struct vfio_ap_queue *q,
+ struct ap_queue_status *status, int ret)
+{
+ memcpy(&q->reset_status, status, sizeof(*status));
+ if (!ret)
+ q->reset_status.response_code = AP_RESPONSE_NORMAL;
+
+ vfio_ap_free_aqic_resources(q);
+}
+
static void apq_reset_check(struct work_struct *reset_work)
{
int ret = -EBUSY, elapsed = 0;
@@ -2182,6 +2239,58 @@ static void apq_reset_check(struct work_struct *reset_work)
memcpy(&q->reset_status, &status, sizeof(status));
return;
}
+
+ if (!ret || ret == -ENODEV) {
+ /*
+ * Zeroization confirmed (ret == 0): the TAPQ status bits
+ * indicate the async portion of the ZAPQ completed
+ * successfully. Free AQIC resources and return.
+ *
+ * Queue non-operational (ret == -ENODEV): the queue is
+ * deconfigured or checkstopped; interrupts are not
+ * possible so AQIC resources can be safely freed.
+ * Zeroization cannot be confirmed in this state, but the
+ * queue cannot generate interrupts, so the NIB page is
+ * no longer a DMA target and it is safe to free it.
+ */
+ apq_reset_finalize(q, &status, ret);
+ return;
+ }
+
+ if (elapsed >= AP_RESET_MAX_WAIT) {
+ /*
+ * Timed out without being able to verify zapq completed.
+ *
+ * The AQIC resources associated with this queue - the pinned
+ * page containing the NIB and the registered guest ISC -
+ * cannot be freed here. The NIB is the active DMA target
+ * for AP interrupt delivery until the reset completes;
+ * freeing the pinned page while the hardware may still
+ * write to it would result in a wild DMA write that could
+ * corrupt host memory.
+ *
+ * If the reset eventually completes, interrupts will be
+ * terminated and the pinned NIB page and ISC registration
+ * will be leaked. This is preferable to either a wild DMA
+ * write or waiting indefinitely: flush_work() callers hold
+ * the matrix_dev->mdevs_lock mutex which serializes access
+ * to all mdev objects system-wide, so blocking here would
+ * hang all guests to which those mdevs are attached.
+ */
+ report_aqic_resource_leak(q);
+ /*
+ * Zeroization could not be confirmed; set
+ * reset_status to AP_RESPONSE_RESET_IN_PROGRESS.
+ * This is used internally to signal that the reset
+ * did not complete, and ensures that if the queue
+ * is reset again, the re-issue logic in
+ * apq_reset_check() will re-issue the ZAPQ.
+ */
+ q->reset_status.response_code = AP_RESPONSE_RESET_IN_PROGRESS;
+
+ return;
+ }
+
if (ret == -EBUSY) {
pr_notice_ratelimited(WAIT_MSG, elapsed,
AP_QID_CARD(q->apqn),
@@ -2189,22 +2298,15 @@ static void apq_reset_check(struct work_struct *reset_work)
status.response_code,
status.queue_empty,
status.irq_enabled);
- } else {
- if (q->reset_status.response_code == AP_RESPONSE_RESET_IN_PROGRESS ||
- q->reset_status.response_code == AP_RESPONSE_BUSY ||
- q->reset_status.response_code == AP_RESPONSE_STATE_CHANGE_IN_PROGRESS ||
- ret == -EAGAIN) {
- status = ap_zapq(q->apqn, 0);
- memcpy(&q->reset_status, &status, sizeof(status));
- continue;
- }
- /*
- * We end up here when the ZAPQ has completed. ZAPQ
- * disables interrupts, so the AQIC resources must be
- * freed; otherwise they will be leaked.
- */
- vfio_ap_free_aqic_resources(q);
- break;
+ continue;
+ }
+
+ if (ret == -EAGAIN ||
+ q->reset_status.response_code == AP_RESPONSE_RESET_IN_PROGRESS ||
+ q->reset_status.response_code == AP_RESPONSE_STATE_CHANGE_IN_PROGRESS) {
+ status = ap_zapq(q->apqn, 0);
+ memcpy(&q->reset_status, &status, sizeof(status));
+ elapsed = 0;
}
}
}
--
2.53.0
next prev parent reply other threads:[~2026-09-25 12:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 12:45 [PATCH v8 0/6] s390/vfio-ap: Fix pre-existing bugs in vfio_ap device driver Anthony Krowiak
2026-09-25 12:45 ` [PATCH v8 1/6] s390/vfio-ap: Fix leaks of pinned NIB and registered GISC Anthony Krowiak
2026-09-25 12:45 ` [PATCH v8 2/6] s390/vfio-ap: Fix failure to release IRQ notification eventfd contexts Anthony Krowiak
2026-09-25 12:45 ` Anthony Krowiak [this message]
2026-09-25 12:45 ` [PATCH v8 4/6] s390/vfio-ap: Use AP_DOMAINS for adm_add bitmap size in vfio_ap_mdev_cfg_add() Anthony Krowiak
2026-09-25 12:45 ` [PATCH v8 5/6] s390/vfio-ap: fix queue state leakage to guest and host Anthony Krowiak
2026-09-25 12:45 ` [PATCH v8 6/6] s390/vfio-ap: replace guest-reachable WARNs with ratelimited warnings Anthony Krowiak
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=20260925124551.665448-4-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=freude@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
all inboxes | Powered by JetHome®