From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 ABCC34266B0; Tue, 31 Mar 2026 16:52:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774975945; cv=none; b=bMNJkKeY3zW5iOxx5KrRVaZEHlv0x6KBSPhebz/Xi3e+1b5JNM2uTz4fRNYGO4AtmgSQ4Sc7htz8q4P0GZlnKZf7LimDHLNS8Db4YhhNIK5jHYZ3mbcI0gVySkef1mpF1QLiFF5uiPXS1sikpiJ94UB05+D7tXex1BbtUr6cHFs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774975945; c=relaxed/simple; bh=Aqax7egA0nO1VaFAM5Cc2w8Ry0w26/mXRJiSVMwGjok=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hSFUTs+9/0j8rrtOhzIPgsdn5g2pYrKx+yhLrUzVeKYK+gr3dc8G2tFJ2B+26Wt2T69DoXSapMBegU/ZCFYH4jVxu37l4j85kEUqblEWQxP+aqUT6d6r5Ym27NcYXHQD9V/dNfiGFcFJAdLtTyUh87mSOvWe5zmunU4gD2TyPD8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=X9Qi0iFi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="X9Qi0iFi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 433ACC19423; Tue, 31 Mar 2026 16:52:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1774975945; bh=Aqax7egA0nO1VaFAM5Cc2w8Ry0w26/mXRJiSVMwGjok=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=X9Qi0iFiReHzFgio+83IT6mT/qSKyEdEEDmlOn8gFE+4ZbwEa0W2yYuXz2jAZu1Di qh1Xk8eFDh0qXKJV+QvDizxMRHXslCCdXWNPPtOCQVjE+CLgGRTg1T5hXhxSEQ/wC+ cSuBx8VnklOLxoXgRiKok0dbysU+Lp2jLpasgQZk= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Suzuki K Poulose , Joey Gouly , Marc Zyngier Subject: [PATCH 6.12 148/244] KVM: arm64: Discard PC update state on vcpu reset Date: Tue, 31 Mar 2026 18:21:38 +0200 Message-ID: <20260331161747.230123393@linuxfoundation.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260331161741.651718120@linuxfoundation.org> References: <20260331161741.651718120@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Marc Zyngier commit 1744a6ef48b9a48f017e3e1a0d05de0a6978396e upstream. Our vcpu reset suffers from a particularly interesting flaw, as it does not correctly deal with state that will have an effect on the execution flow out of reset. Take the following completely random example, never seen in the wild and that never resulted in a couple of sleepless nights: /s - vcpu-A issues a PSCI_CPU_OFF using the SMC conduit - SMC being a trapped instruction (as opposed to HVC which is always normally executed), we annotate the vcpu as needing to skip the next instruction, which is the SMC itself - vcpu-A is now safely off - vcpu-B issues a PSCI_CPU_ON for vcpu-A, providing a starting PC - vcpu-A gets reset, get the new PC, and is sent on its merry way - right at the point of entering the guest, we notice that a PC increment is pending (remember the earlier SMC?) - vcpu-A skips its first instruction... What could possibly go wrong? Well, I'm glad you asked. For pKVM as a NV guest, that first instruction is extremely significant, as it indicates whether the CPU is booting or resuming. Having skipped that instruction, nothing makes any sense anymore, and CPU hotplugging fails. This is all caused by the decoupling of PC update from the handling of an exception that triggers such update, making it non-obvious what affects what when. Fix this train wreck by discarding all the PC-affecting state on vcpu reset. Fixes: f5e30680616ab ("KVM: arm64: Move __adjust_pc out of line") Cc: stable@vger.kernel.org Reviewed-by: Suzuki K Poulose Reviewed-by: Joey Gouly Link: https://patch.msgid.link/20260312140850.822968-1-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman --- arch/arm64/kvm/reset.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/arch/arm64/kvm/reset.c +++ b/arch/arm64/kvm/reset.c @@ -257,6 +257,20 @@ void kvm_reset_vcpu(struct kvm_vcpu *vcp kvm_vcpu_set_be(vcpu); *vcpu_pc(vcpu) = target_pc; + + /* + * We may come from a state where either a PC update was + * pending (SMC call resulting in PC being increpented to + * skip the SMC) or a pending exception. Make sure we get + * rid of all that, as this cannot be valid out of reset. + * + * Note that clearing the exception mask also clears PC + * updates, but that's an implementation detail, and we + * really want to make it explicit. + */ + vcpu_clear_flag(vcpu, PENDING_EXCEPTION); + vcpu_clear_flag(vcpu, EXCEPT_MASK); + vcpu_clear_flag(vcpu, INCREMENT_PC); vcpu_set_reg(vcpu, 0, reset_state.r0); }