From nobody Sun Sep 27 00:39:10 2026 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4BC334746B7; Thu, 27 Aug 2026 13:24:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787837103; cv=none; b=D5J8rN8T/wLYVgt+b7ZlySN3NBa9fBdp0FNR74a+4gtFbYIqXlkz9atl09nlu8P7f8v2OLl8FyRNeXxosyf5SGjyHNPRxA5llm/toANvIJk9A2VPQ+vBVnfubiQWvugaT/Oi0Hkx0rmYsDiQMDmxRCfUAX4viGHHUqhW9bhJJAI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787837103; c=relaxed/simple; bh=4n+c3ea4Xo1jTF8SUOiroQOh0rJvWjGxWW5Oqm15EPk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fCLpsAp2U5giNFA9HboAsyoaHIQY/uvKcIrArDYEZnVyECvn3ZWjldjWGycChSb1rBCbX5SRH/3fOdLKllHID8wDeeH4k8JfRabOD9hZtrhoDqlE+aS/E5ib1XT3mEhiXineKoKZVc3WgC13BbopC5ZAnt7aHljmsvaxOmEb+Kk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=CdGe59cA; arc=none smtp.client-ip=148.163.158.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="CdGe59cA" Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67RCVmQD2892086; Thu, 27 Aug 2026 13:24:48 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=pp1; bh=gIqAPNMmMJOHw8XI4 ucbyIGPlYtT2uZxL1KAuxc+bx0=; b=CdGe59cAODjKPqohWS0mPW/L4fL6oKB34 DFofks/O1cCCtKjCrXyDfoohejik37IFcLLJOtLa9oxyD6E1kTnHnIsBdxjEWpm3 +c2kVqmQ+bdx90ZVhIdEcl2NbljFwqOD5J0a+EGnNsgqowYiN6ZxSh3c7NoDnO6d 252DhqigvJ7/ESFAH5JfZ+t4tJTwwrdDWFO6cNQ3AiCdHjBhQ11EIgiMyqY7f53V oaq5bU5f+0aSDZ3XkFS8um6E+8PeWQb6TZJLx9l1XfPO1Klz2hvTRHw6pHqCA45O CUhNquDU2I7Mq+hwJsc5bivQFqcS51ntuaAhnjmFMki+HYrBPIEgg== Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4g716j5n5a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2026 13:24:47 +0000 (GMT) Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 67RDBKM3025548; Thu, 27 Aug 2026 13:24:46 GMT Received: from smtprelay02.wdc07v.mail.ibm.com ([172.16.1.69]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 4g7p3qgg3u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2026 13:24:46 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (smtpav01.dal12v.mail.ibm.com [10.241.53.100]) by smtprelay02.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 67RDOj7n23527980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Aug 2026 13:24:45 GMT Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0344758059; Thu, 27 Aug 2026 13:24:45 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C47C158058; Thu, 27 Aug 2026 13:24:43 +0000 (GMT) Received: from li-4c4c4544-004d-4810-8043-b7c04f423534.ibm.com.com (unknown [9.61.15.38]) by smtpav01.dal12v.mail.ibm.com (Postfix) with ESMTP; Thu, 27 Aug 2026 13:24:43 +0000 (GMT) From: Anthony Krowiak 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 Message-ID: <20260827132441.555866-2-akrowiak@linux.ibm.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260827132441.555866-1-akrowiak@linux.ibm.com> References: <20260827132441.555866-1-akrowiak@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-TM-AS-GCONF: 00 X-Proofpoint-Spam-Info: AW1haW4tMjYwODI3MDEwOSBTYWx0ZWRfX8OEJPMxPYWOI gWFbVZD+fpeIZ5iOzYCHcmm8bzY8me2Swan/Swhgwi+7u0Y3xkTJc4aiTy9Yhl3hL6D4//wFWyV B14/Sypa4I1jQc6QjJQ8YVguLYd0KTU= X-Proofpoint-GUID: fPpZXE62gu-LVm433UvXSvvIIssa0c7y X-Proofpoint-ORIG-GUID: fPpZXE62gu-LVm433UvXSvvIIssa0c7y X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI3MDEwOSBTYWx0ZWRfXxpvuuKXywMKQ pmeAGBxPQc5X5nmzknsK2dVv9p9Ea50x3P4u0v553F0VXv+oKcc2HongbAhc67F9oeLgxnUs0Zd i7T5YiL5eQkbBZxlZfW/Vuy9wch7jCajJg7jiioX/UmRDnMqXlQZmh0Eev103hpreB7Wh2MpO+K Dn/DMhFjJjsM6a4m2yrkZD1hKMu/jp4Em37adk+CyhzUF8VnWTCdqGNfEWMnekvFAmrQB9LmmL8 NJn5g/wpdCGJ9OskGFLkHbBRjLoDbbruMYerSQvMsVQb+YG0OqkLsxRFsI6TGzfNDoPH55Fcfda NUomY+q3S/1/qgPaz8/PtQKGIZTGxGb0R86zZ756ph4jVNJCakvDoTnhSCZqR0xH2cxfXXTjtM1 Ut7ekEo8pTN1sPuqh8/gaGhadthpWO/kFM34IqlhnQP7d4dB17auDdbbAoqOQlJ5ELL3vvq2U9p 3fb7D53pprI7ty3Fppw== X-Authority-Analysis: v=2.4 cv=H7brBeYi c=1 sm=1 tr=0 ts=6a903a9f cx=c_pps a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=Y2IxJ9c9Rs8Kov3niI8_:22 a=VwQbUJbxAAAA:8 a=VnNF1IyMAAAA:8 a=pD7fxfrtpoTVUSxl-N4A:9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-27_05,2026-08-26_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 impostorscore=0 spamscore=0 bulkscore=0 adultscore=0 priorityscore=1501 clxscore=1015 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608270109 Content-Type: text/plain; charset="utf-8" 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 --- 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_a= p_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( } =20 /** - * 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 q= ueue + * * @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 callin= g the + * PQAP(TAPQ) instruction every 20ms until: the IR bit is cleared; the res= ponse + * 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 wh= ich + * case no further interrupts can be generated) + * + * - false if the IR bit is still set after all retries are exhausted, mea= ning + * 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 =3D 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); =20 - 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 f= or %02x.%04x\n", + __func__, status.response_code, AP_QID_CARD(apqn), AP_QID_QUEUE(apqn)); + return false; } =20 /** @@ -317,8 +326,21 @@ static struct ap_queue_status vfio_ap_irq_disable(stru= ct 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(str= uct 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--); =20 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(struc= t vfio_ap_queue *q, q->saved_isc =3D 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=3D3 indicating the new NIB and ISC were not accepted by + * the hardware, so clean them up. + */ ret =3D kvm_s390_gisc_unregister(kvm, isc); if (ret) VFIO_AP_DBF_WARN("%s: kvm_s390_gisc_unregister: rc=3D%d isc=3D%d, apqn= =3D%#04x\n", @@ -503,9 +558,12 @@ static struct ap_queue_status vfio_ap_irq_enable(struc= t 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 =3D kvm_s390_gisc_unregister(kvm, isc); + if (ret) + VFIO_AP_DBF_WARN("%s: kvm_s390_gisc_unregister: rc=3D%d isc=3D%d, apqn= =3D%#04x\n", + __func__, ret, isc, q->apqn); + vfio_unpin_pages(&q->matrix_mdev->vdev, nib, 1); break; } =20 @@ -635,7 +693,6 @@ static int handle_pqap(struct kvm_vcpu *vcpu) } =20 status =3D vcpu->run->s.regs.gprs[1]; - /* If IR bit(16) is set we enable the interrupt */ if ((status >> (63 - 16)) & 0x01) qstatus =3D vfio_ap_irq_enable(q, status & 0x07, vcpu); --=20 2.53.0 From nobody Sun Sep 27 00:39:10 2026 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 01A06474265; Thu, 27 Aug 2026 13:25:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787837110; cv=none; b=qxW/KTKJhnilWIEaH528Md8D47pw6ufb0feEkDc+NIy3cFSYti3r6L0Qrp8iQLk9QYsqIkbVEqzIFb1DDuivuIApmhtCI4isx2tou9P7tzD81DVAJt0Q2rs0BChZijKaBwwjOsx5mPCZ2lZyhtA62YzcCQ6xNaBWAIy5Um827/0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787837110; c=relaxed/simple; bh=JZd0x7MD0E1j4ttNUg9a64KnRRaSKa78umgf3Cm3Kkg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MiRft6vaBZDfZGRLj6cJvFfad9FVm1P4RwsvykPbtNtwz6XXjan32q+okSDe2VtW1stASxc48K2M2l//gBonBXAws6p6y0bdtxGFfuXwItFoAQNwbnX1oKzqhsq67Maz81X34nKvOlhQh/FcJNQQWEj5BRKS9DU12uzCpenPy6w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=SBFeiWWw; arc=none smtp.client-ip=148.163.156.1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="SBFeiWWw" Received: from pps.filterd (m0356517.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67RCVlEn3002174; Thu, 27 Aug 2026 13:24:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=pp1; bh=6yxN+EPrcRQQdosBb HAdPltupz2JJpNreDVU+CT/Z8s=; b=SBFeiWWw5MRCOyGBIxpRLg7QL3+zxlZFz JFXNy9zgHTLcjYnFjVmebmBHlZDhL1iFs7XbIN4oECW2b8nRMAhGvxNRUpQ6bPv2 FMH+JKdcIwAEdipko5sgy1rwFA/E3oZmV8oAvsqxYch9uACKlu/0P02UsXfMv9SR P6Vdii6tN+yv70kFsg5YQiPFZcVEShNe2nq9QeFvt4PJUR8lCIDp4elkVqfS9s+R riXGhOhTW1aMhBmmmsRnJQyw8fbkxh4zcqlJfQKnWBvglo8OM4bk+mPKwPPPb8ZY fR0PceLh+QSm96e7XDJS/Ze5PS6MkFvx1OB5e9IWQ52yocZNB0BvQ== Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4g73g55n1a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2026 13:24:48 +0000 (GMT) Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 67RDBK3M016287; Thu, 27 Aug 2026 13:24:47 GMT Received: from smtprelay03.wdc07v.mail.ibm.com ([172.16.1.70]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4g7pfwgbr9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2026 13:24:47 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (smtpav01.dal12v.mail.ibm.com [10.241.53.100]) by smtprelay03.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 67RDO6Fv63963562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Aug 2026 13:24:06 GMT Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 52AFE58065; Thu, 27 Aug 2026 13:24:46 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 223F658058; Thu, 27 Aug 2026 13:24:45 +0000 (GMT) Received: from li-4c4c4544-004d-4810-8043-b7c04f423534.ibm.com.com (unknown [9.61.15.38]) by smtpav01.dal12v.mail.ibm.com (Postfix) with ESMTP; Thu, 27 Aug 2026 13:24:45 +0000 (GMT) From: Anthony Krowiak 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 2/4] s390/vfio-ap: Fix failure to release IRQ notification eventfd contexts Date: Thu, 27 Aug 2026 09:24:28 -0400 Message-ID: <20260827132441.555866-3-akrowiak@linux.ibm.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260827132441.555866-1-akrowiak@linux.ibm.com> References: <20260827132441.555866-1-akrowiak@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 3xQWGb-Fn6sOFIJhLN_eMcF-000nhamj X-Proofpoint-Spam-Info: AW1haW4tMjYwODI3MDEwOSBTYWx0ZWRfX0rfbbgeYyvwq /rF67ikoMkfZjHWEcbLJNDEOdkuJLSmwIXjIxiTng8sj7oqVh4nyKOQGQGrh+KJO/gS/eKpR0Sc FGawuvLPl/XAm0OwCLKxDFKTE+cJT+Y= X-Proofpoint-GUID: 3xQWGb-Fn6sOFIJhLN_eMcF-000nhamj X-Authority-Analysis: v=2.4 cv=JZyMa0KV c=1 sm=1 tr=0 ts=6a903aa1 cx=c_pps a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=U7nrCbtTmkRpXpFmAIza:22 a=VwQbUJbxAAAA:8 a=VnNF1IyMAAAA:8 a=fxeDLeT5AZ2qCvnLJ4gA:9 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI3MDEwOSBTYWx0ZWRfXxtJeGJkG1Hml da/+a70/ldsQ4F+MMBOGhlAgPvgAEZV2As3gGibYQLrA/hLssMjxAYTUekEluFnRUI+8QgWRT94 E9n8FQBB/lpA9TqhG5GnuqVR0DaLykE8LunwPugb0JRtyBVx2ICwUmeoycoVYDlcfNKDZYe377A 8ttS45exceFzna5lgqdEyXUbNl+e7W5podssRZZcnfIcwKTMePIasPmX0xH94SiMWMe+gj0EE2u YC9J48xnHeAzUXeQvV/o/CzgJ/alb329QeW7/2XsqgQNXVKTxusgqfMq0bLgh8Qg+J4/Bz/CkBS lpCgvGbLzj0+vzq5WMXfymGaMHAL29nFc1BsIMbDDdj1+Z1rZglSU72WcDuVHShr+rpCF9ls99V VrPq3P1qH8jFnXkFfn0uNyQNZVNIUVIjVjJxOExNbuNqx5l/e4ttPYSlbQXlz78n/hGiZ01VvWA BwZpYSgtfSztpKtFBsA== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-27_05,2026-08-26_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1015 adultscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 bulkscore=0 lowpriorityscore=0 suspectscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608270109 Content-Type: text/plain; charset="utf-8" When userspace registers IRQ notification eventfds via the VFIO_DEVICE_SET_IRQS ioctl, vfio_ap_set_request_irq() and vfio_ap_set_cfg_change_irq() each call eventfd_ctx_fdget(), which takes a reference on the eventfd_ctx and stores it in matrix_mdev->req_trigger and matrix_mdev->cfg_chg_trigger respectively. These references are dropped only when userspace explicitly replaces or clears them via a subsequent SET_IRQS call. If the device is closed without that explicit teardown - because the guest exits, the VM process crashes, or the device file is simply closed - neither vfio_ap_mdev_close_device() nor the remove path releases these references. The eventfd_ctx backing objects and their associated file references therefore leak for the lifetime of the kernel. Fix this by introducing vfio_ap_mdev_release_eventfds() and calling it from vfio_ap_mdev_close_device() after vfio_ap_mdev_unset_kvm(). The VFIO core guarantees that close_device is called before vfio_unregister_group_dev() returns in the remove path, so fixing close_device is sufficient to cover both teardown paths. Note: ~~~~ The matrix_dev->mdevs lock must be held during the call to vfio_ap_mdev_release_eventfds(). There is a small window between the calls to vfio_ap_mdev_unset_kvm() which gets and releases the update locks and the acquisition of the matrix_dev->mdevs_lock mutex during which it is possible - although highly unlikely during normal operation - whereby a concurrent SET_IRQS call can get in. Taking matrix_dev->mdevs_lock around vfio_ap_mdev_release_eventfds() is sufficient to make this race-free. The SET_IRQS ioctl path writes req_trigger and cfg_chg_trigger only from vfio_ap_mdev_ioctl(), which holds mdevs_lock for its entire duration and always calls eventfd_ctx_put() on the previous value before storing the new one. Any number of concurrent SET_IRQS calls during the window between vfio_ap_mdev_unset_kvm() and the acquisition of mdevs_lock are therefore safe: each ioctl invocation puts the reference it found and installs a new one, leaving exactly one live reference in the field when it releases the lock. When release_eventfds subsequently acquires mdevs_lock it finds that single surviving reference and puts it. Conversely, a SET_IRQS call that loses the race and blocks on mdevs_lock will find the field NULL after release_eventfds finishes, take ownership of the reference it just created, and install it into a field that will never be read again - a transient leak. To close that final case, callers must ensure no new SET_IRQS ioctls can be issued after close_device() is called, which the VFIO core guarantees by releasing the device file before invoking close_device(). Fixes: bf48961f6f48e ("s390/vfio-ap: realize the VFIO_DEVICE_SET_IRQS ioctl= ") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak Reviewed-by: Matthew Rosato --- drivers/s390/crypto/vfio_ap_ops.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_a= p_ops.c index 64d6a8f8fa96..4c32fd6eaaa6 100644 --- a/drivers/s390/crypto/vfio_ap_ops.c +++ b/drivers/s390/crypto/vfio_ap_ops.c @@ -2118,12 +2118,28 @@ static int vfio_ap_mdev_open_device(struct vfio_dev= ice *vdev) return vfio_ap_mdev_set_kvm(matrix_mdev, vdev->kvm); } =20 +static void vfio_ap_mdev_release_eventfds(struct ap_matrix_mdev *matrix_md= ev) +{ + if (matrix_mdev->req_trigger) { + eventfd_ctx_put(matrix_mdev->req_trigger); + matrix_mdev->req_trigger =3D NULL; + } + if (matrix_mdev->cfg_chg_trigger) { + eventfd_ctx_put(matrix_mdev->cfg_chg_trigger); + matrix_mdev->cfg_chg_trigger =3D NULL; + } +} + static void vfio_ap_mdev_close_device(struct vfio_device *vdev) { struct ap_matrix_mdev *matrix_mdev =3D container_of(vdev, struct ap_matrix_mdev, vdev); =20 vfio_ap_mdev_unset_kvm(matrix_mdev); + + mutex_lock(&matrix_dev->mdevs_lock); + vfio_ap_mdev_release_eventfds(matrix_mdev); + mutex_unlock(&matrix_dev->mdevs_lock); } =20 static void vfio_ap_mdev_request(struct vfio_device *vdev, unsigned int co= unt) --=20 2.53.0 From nobody Sun Sep 27 00:39:10 2026 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E9A8A4746B3; Thu, 27 Aug 2026 13:24:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787837103; cv=none; b=GeM+TaHUgXf+rVQiuvk22CK1dS/gY7mUishDs34YddemsVJQVHfDHQHZblnQZRwCq81teDyWj+akJCA268rAMsOJ5P0M7dCpQunUM+L8bL4m3E4geeELmGhEKXHe6ooy66EyigUv38r+5HTWZpV05QJTxvtkiE1BRrGEXObwtrw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787837103; c=relaxed/simple; bh=DW5ur2GDgaG0fQ1YnY1EXxVbeJL9kHSUUwchijPqb08=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SS5r3LPEz8eMTqXpVw8IiyQ5dB63wqW9oYb7dUDeydCloI9m24LUK5R0yPs4lT99BWLfELlyraiRd6Df1QaR/qRVuV33vDs8AnRnNepYbqGRPU5l9Xdfp/XjJr0/3jr6KVzFFCD2mYmx1zz7l5gL7rPB66KNZfe3ugiaEdbeP1w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=T2JcyhzH; arc=none smtp.client-ip=148.163.158.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="T2JcyhzH" Received: from pps.filterd (m0360072.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67RCVfGM3056500; Thu, 27 Aug 2026 13:24:50 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=pp1; bh=y//a/1dejuvCbPOiC esY4wmqgti970P35/cIGN/9af4=; b=T2JcyhzHL3SeLLzYFlDwbwxfM/cRKrSU9 FP+s2A2v+dpDSF2FGs4r52nnaYtBBrxkOC4iQe4l0bfsE5lU7dqabzYLtJAP0+zj 8ytw3B3hGTn+p7vuzBR+jTIhaJYFLE3BzA7e008jZk7p87rvNjljvjAQwhhb9uHR 1AMWWmmqyAesTw0eM6tFfdTaPxq5k4M47RV+jJ3KbMO9q8V1ib+sJ003ba+6Yex2 8toO1Wm+fyU6x+8cgzGX4zjoeXUFd7Lm/8TnWqkoICJfInY56GZtk0D6XdVOAhHC LudBeyBAv+p1m7GifiaTvVWZK3caIXBMtgNUnJS8zZXdAKA15YmPg== Received: from ppma23.wdc07v.mail.ibm.com (5d.69.3da9.ip4.static.sl-reverse.com [169.61.105.93]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4g73dxn84g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2026 13:24:49 +0000 (GMT) Received: from pps.filterd (ppma23.wdc07v.mail.ibm.com [127.0.0.1]) by ppma23.wdc07v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 67RCuGYJ031730; Thu, 27 Aug 2026 13:24:49 GMT Received: from smtprelay04.wdc07v.mail.ibm.com ([172.16.1.71]) by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4g7qkhg6n0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2026 13:24:49 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (smtpav01.dal12v.mail.ibm.com [10.241.53.100]) by smtprelay04.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 67RDOlxH33817288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Aug 2026 13:24:48 GMT Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A35535806B; Thu, 27 Aug 2026 13:24:47 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 71F7F58057; Thu, 27 Aug 2026 13:24:46 +0000 (GMT) Received: from li-4c4c4544-004d-4810-8043-b7c04f423534.ibm.com.com (unknown [9.61.15.38]) by smtpav01.dal12v.mail.ibm.com (Postfix) with ESMTP; Thu, 27 Aug 2026 13:24:46 +0000 (GMT) From: Anthony Krowiak 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 3/4] s390/vfio-ap: Fix unbounded loop in apq_reset_check() Date: Thu, 27 Aug 2026 09:24:29 -0400 Message-ID: <20260827132441.555866-4-akrowiak@linux.ibm.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260827132441.555866-1-akrowiak@linux.ibm.com> References: <20260827132441.555866-1-akrowiak@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-TM-AS-GCONF: 00 X-Proofpoint-Spam-Info: AW1haW4tMjYwODI3MDEwOSBTYWx0ZWRfX8izkl8UHCXN/ NGjmIX1VQT+sIn1lX8br1Wjf0J5eb4fC+MKCCgSQcfhqgSSSDVaoDKmyVxzhZfjZIn6B4pmLFR+ MGMercti2jQTIRzq0kYYyfi2e7u98Rs= X-Authority-Analysis: v=2.4 cv=AYuB2XXG c=1 sm=1 tr=0 ts=6a903aa1 cx=c_pps a=3Bg1Hr4SwmMryq2xdFQyZA==:117 a=3Bg1Hr4SwmMryq2xdFQyZA==:17 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=RzCfie-kr_QcCd8fBx8p:22 a=VwQbUJbxAAAA:8 a=VnNF1IyMAAAA:8 a=qRifxZYimwebPS9KaUgA:9 X-Proofpoint-ORIG-GUID: XJUstwI26qh1Kac69caNV2xLmf0rIPjG X-Proofpoint-GUID: XJUstwI26qh1Kac69caNV2xLmf0rIPjG X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI3MDEwOSBTYWx0ZWRfXwJPId3/NJsAj YJeHBeBcvMhhKBE+Vwq2sW7iQY9GBhj9Sb/uimUJQSqWzvj60pQTzJO+MOyq9trAoqy1jxENHwP n0Qi8P3WOwFiFbX0bRgCY4AKWay9GpR3bbqCSGts46OjdzKMQ+K49OHbF7loBkvLwqJgiyqv+8v ZyWH+mVpqtXgpREUM+MPbnHsXGLcf/uMNxE+9t7/giohBZpuTtrQJD3FzPUGnjLYaURH2FNoskB o2IPXMnBI7xAM6sbMHj4ToYRsF+lXTHIZG+uLmFALPCEmJUOg3Z6OIMWyYHtZHxaSpgyy26/+8O 7ZoOL69LnETKCtk+ZS4eNAgzr++FplU5U24eHBvPL7qGFE0LJDbyTzCtmewdGmdilNWZD5GXnNh 9peTdBpROhAsKbImSilLPiqw3k0vw4kv/qGGKus5VFqY3iTEL3bFvT76zyyj5f5HcXitePD5TfR BnhWGNMcsyJ0/s4WYtw== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-27_05,2026-08-26_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 phishscore=0 clxscore=1015 adultscore=0 bulkscore=0 impostorscore=0 priorityscore=1501 lowpriorityscore=0 spamscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608270109 Content-Type: text/plain; charset="utf-8" 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 or AP_RESPONSE_RESET_IN_PROGRESS, apq_status_check() returns -EBUSY and the loop continues after sleeping AP_RESET_MAX_WAIT (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_queues() and vfio_ap_mdev_reset_qlist() call flush_work() on each 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 all of those locks, hanging mdev removal, KVM guest teardown, and the VFIO_DEVICE_RESET ioctl path. Fix this by introducing AP_RESET_MAX_WAIT (2000ms) and breaking out of the poll loop when elapsed time reaches that threshold. On timeout the final busy status is written back to q->reset_status so that callers inspecting reset_status.response_code after flush_work() see a non-zero value and can return an appropriate error. The AQIC resources associated with this queue - the pinned page containing the NIB and the registered guest ISC - cannot be freed in this case. 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 use-after-free kernel crash. If the reset eventually completes, interrupts will be terminated, but the pinned NIB page and ISC registration will be leaked. This is preferable to either a use-after-free or waiting indefinitely. Fixes: dd174833e44e ("s390/vfio-ap: remove upper limit on wait for queue re= set to complete") Cc: stable@vger.kernel.org Signed-off-by: Anthony Krowiak --- drivers/s390/crypto/vfio_ap_ops.c | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_a= p_ops.c index 4c32fd6eaaa6..a9a33f4949a0 100644 --- a/drivers/s390/crypto/vfio_ap_ops.c +++ b/drivers/s390/crypto/vfio_ap_ops.c @@ -31,6 +31,7 @@ #define AP_QUEUE_IN_USE "in use" =20 #define AP_RESET_INTERVAL 20 /* Reset sleep interval (20ms) */ +#define AP_RESET_MAX_WAIT 2000 /* Maximum wait for reset (2000ms) */ =20 static int vfio_ap_mdev_reset_queues(struct ap_matrix_mdev *matrix_mdev); static int vfio_ap_mdev_reset_qlist(struct list_head *qlist); @@ -2016,8 +2017,32 @@ static void apq_reset_check(struct work_struct *rese= t_work) elapsed +=3D AP_RESET_INTERVAL; status =3D ap_tapq(q->apqn, NULL); ret =3D apq_status_check(q->apqn, &status); - if (ret =3D=3D -EIO) + if (ret =3D=3D -EIO) { + memcpy(&q->reset_status, &status, sizeof(status)); return; + } + if (elapsed >=3D AP_RESET_MAX_WAIT) { + /* + * Timed out waiting for reset to complete. + * + * 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 use-after-free + * kernel crash. + * + * 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 use-after-free or waiting indefinitely: + * the caller of apq_reset_check() holds mdevs_lock while flush_work() + * blocks holds the matrix_dev->mdevs_lock mutex, which + * serializes access to all mdev objects system-wide, so blocking + * here would stall all other guests using AP queues. + */ + memcpy(&q->reset_status, &status, sizeof(status)); + return; + } if (ret =3D=3D -EBUSY) { pr_notice_ratelimited(WAIT_MSG, elapsed, AP_QID_CARD(q->apqn), --=20 2.53.0 From nobody Sun Sep 27 00:39:10 2026 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F86A471401; Thu, 27 Aug 2026 13:25:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787837105; cv=none; b=C6GvzTikSenAIxjRJGaqJ+qv2l/xCrHOtwl7s+TYy9M2CtiVCaPnOYkRDU3JYeAUp7fkXFmiMDUPvawg+DcrdJfmJZ1avPdOjc1XeXV2v30muEpSMzYszXl0C9qG9Ay78Dj9o4lqFGcV2XpEBJiLSDbEFmz/MeBWsLqfUXL4lqQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787837105; c=relaxed/simple; bh=Vj6TEpH754140Zk8NGOPD5XhRjpHB5zOygV7VtZHsi8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qGIerKLhrXdojEQ4qITAv5Zf2x4DiS4JWR81bV01AdmJP8uUAF72Jj+1KOALXxZWPBk0Wz0cJ3EsPG4Mob5dX/T/xSa3DmT5w5oDFBBCWDpXLy7pSsc5BnbJ7mZycoXZ0/iLRpx5oc7tvBVeUO53yOz0myTRrtwt0V5EI5//Kfc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=D3M31WO9; arc=none smtp.client-ip=148.163.156.1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="D3M31WO9" Received: from pps.filterd (m0356517.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67RCVSKB3001315; Thu, 27 Aug 2026 13:24:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=pp1; bh=QX7cDrPFlwXDSlsvF YYszKsDaHL6g+PXOll/E4cQIVg=; b=D3M31WO9nXVb7AOd5vu+6g0ER1UUiHwU1 we+OjDCTkQt9gYP8EH3gSBvZYvgRK/2/3H6QKknLj7scJcmeFembVPoR9jecy+2G 3rzz3/uMW8/LKZ/pmFI85Bl+CTf33HnKsAPsJ3cKmlMxTMSe3JZgUh31eOB8kXni EzNQcmnTYDNrX5nBCmpFXkvEz9v4gUw92ScPs71eneShJSGCUq39aTHEI4bnS+lu sC3CFHJ/0MtVU6VkelnWoLYM8XMu3ogFANx6WOSfRl51v73nBztcdUyJjA7269BS UzPSD1FE8ai0uIMbxPpOlI550UuFaHm2Unz6C1BNoKLqkrzoyaQgA== Received: from ppma23.wdc07v.mail.ibm.com (5d.69.3da9.ip4.static.sl-reverse.com [169.61.105.93]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4g73g55n1k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2026 13:24:51 +0000 (GMT) Received: from pps.filterd (ppma23.wdc07v.mail.ibm.com [127.0.0.1]) by ppma23.wdc07v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 67RCuIdi031744; Thu, 27 Aug 2026 13:24:50 GMT Received: from smtprelay06.wdc07v.mail.ibm.com ([172.16.1.73]) by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4g7qkhg6n4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2026 13:24:50 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (smtpav01.dal12v.mail.ibm.com [10.241.53.100]) by smtprelay06.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 67RDOnsC17105610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Aug 2026 13:24:49 GMT Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EC63658063; Thu, 27 Aug 2026 13:24:48 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C10C458065; Thu, 27 Aug 2026 13:24:47 +0000 (GMT) Received: from li-4c4c4544-004d-4810-8043-b7c04f423534.ibm.com.com (unknown [9.61.15.38]) by smtpav01.dal12v.mail.ibm.com (Postfix) with ESMTP; Thu, 27 Aug 2026 13:24:47 +0000 (GMT) From: Anthony Krowiak 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 Subject: [PATCH v3 4/4] s390/vfio-ap: Use AP_DOMAINS for adm_add bitmap size in vfio_ap_mdev_cfg_add() Date: Thu, 27 Aug 2026 09:24:30 -0400 Message-ID: <20260827132441.555866-5-akrowiak@linux.ibm.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260827132441.555866-1-akrowiak@linux.ibm.com> References: <20260827132441.555866-1-akrowiak@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: KjSa6wO28bNNz6HGgg4CfZDpJ8DNXcF7 X-Proofpoint-Spam-Info: AW1haW4tMjYwODI3MDEwOSBTYWx0ZWRfXyQVZALFrxdXy 3Ahdo614f9Ki4Tpq7v8m6SPl61h6YINhspRVwUGHOTbB0V0e7/n7wZw9cR1yD03unDN7rowknIo XqlP7Zk8JKP+VihmdZCIXx0iI+t2LoI= X-Proofpoint-GUID: KjSa6wO28bNNz6HGgg4CfZDpJ8DNXcF7 X-Authority-Analysis: v=2.4 cv=JZyMa0KV c=1 sm=1 tr=0 ts=6a903aa3 cx=c_pps a=3Bg1Hr4SwmMryq2xdFQyZA==:117 a=3Bg1Hr4SwmMryq2xdFQyZA==:17 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=U7nrCbtTmkRpXpFmAIza:22 a=VnNF1IyMAAAA:8 a=gReD5cTbzgwmqpVxveEA:9 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI3MDEwOSBTYWx0ZWRfX2vTm7h++b5Fr 7xUYSKhkB6igTxVCI8jiYTm36HBxPd3cW/xk5gvY0u2b+JxNGXU9kdPaoZiQrY90GfVP2rUgnK9 cVbTYp2Bay0WlsVOzvGpfEzuBXjYkB8d23AKr6pxuTzEjg9q5rwJzNESbK0zct7KfIX6hVwObC2 5LFKO0YZPHJIWApkMKUdGAbC6e7rpXiURjP5XFkCUKQVHWH+h2ePYGwsEbHJDNUD0W/c6DbZ7qS Il6kGELmoH3FaogEui8cB6qrc1wsabdsH/Pso4N2a0/dnZrgKRzUH28aX4VhpksWvq+2q+CpF4e qIeRXpBHOcPWhABk7rDd6R/zKclzQ1RqXR0syTtd5eULrXerdTOkkhPIDfGxVHpRHs8hMe9rZ2u gICSeewDoZJgmHqysfSWk+Eoxsa8Mvxvfdb0Xm1Yuce7ZFx1qwTkxeyKpJu492IiDKH8GX9yM74 hoNmPdkHacWGG+wXJ4g== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-27_05,2026-08-26_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1015 adultscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 bulkscore=0 lowpriorityscore=0 suspectscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608270109 Content-Type: text/plain; charset="utf-8" Domain and control domain bitmaps are sized by the AP_DOMAINS constant, not AP_DEVICES. The two constants are both 256 today so there is no functional impact, but using the wrong constant is inconsistent with every operation on aqm/adm bitmaps. Use AP_DOMAINS to keep the code consistent and correct in case the two constants ever diverge. Note: This patch was submitted in response to a sashiko review comment pointing out there are other functions besides vfio_ap_mdev_cfg_add(), so there are fixes included here for those also. The subject line was kept the same since this is in v2 of this patch. Signed-off-by: Anthony Krowiak --- drivers/s390/crypto/vfio_ap_ops.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_a= p_ops.c index a9a33f4949a0..85a59730019e 100644 --- a/drivers/s390/crypto/vfio_ap_ops.c +++ b/drivers/s390/crypto/vfio_ap_ops.c @@ -1468,7 +1468,7 @@ static void vfio_ap_mdev_hot_unplug_domain(struct ap_= matrix_mdev *matrix_mdev, { DECLARE_BITMAP(apqis, AP_DOMAINS); =20 - bitmap_zero(apqis, AP_DEVICES); + bitmap_zero(apqis, AP_DOMAINS); set_bit_inv(apqi, apqis); vfio_ap_mdev_hot_unplug_domains(matrix_mdev, apqis); } @@ -2795,11 +2795,11 @@ static void vfio_ap_mdev_on_cfg_remove(struct ap_co= nfig_info *cur_config_info, do_remove |=3D bitmap_andnot(aqrem, (unsigned long *)prev_config_info->aqm, (unsigned long *)cur_config_info->aqm, - AP_DEVICES); + AP_DOMAINS); do_remove |=3D bitmap_andnot(cdrem, (unsigned long *)prev_config_info->adm, (unsigned long *)cur_config_info->adm, - AP_DEVICES); + AP_DOMAINS); =20 if (do_remove) vfio_ap_mdev_cfg_remove(aprem, aqrem, cdrem); @@ -2910,7 +2910,7 @@ static void vfio_ap_mdev_cfg_add(unsigned long *apm_a= dd, unsigned long *aqm_add, bitmap_and(matrix_mdev->aqm_add, matrix_mdev->matrix.aqm, aqm_add, AP_DOMAINS); bitmap_and(matrix_mdev->adm_add, - matrix_mdev->matrix.adm, adm_add, AP_DEVICES); + matrix_mdev->matrix.adm, adm_add, AP_DOMAINS); =20 mutex_unlock(&matrix_dev->mdevs_lock); } --=20 2.53.0