From: Greg Kroah-Hartman Date: Mon, 30 Mar 2026 09:22:42 +0000 (+0200) Subject: drop kvm patch from 5.10 and 5.15 X-Git-Tag: v6.6.131~42 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=558d998108fac12ac179b58645c56707c5c1834a;p=thirdparty%2Fkernel%2Fstable-queue.git drop kvm patch from 5.10 and 5.15 --- diff --git a/queue-5.10/kvm-arm64-discard-pc-update-state-on-vcpu-reset.patch b/queue-5.10/kvm-arm64-discard-pc-update-state-on-vcpu-reset.patch deleted file mode 100644 index fa44d0a6e8..0000000000 --- a/queue-5.10/kvm-arm64-discard-pc-update-state-on-vcpu-reset.patch +++ /dev/null @@ -1,81 +0,0 @@ -From 1744a6ef48b9a48f017e3e1a0d05de0a6978396e Mon Sep 17 00:00:00 2001 -From: Marc Zyngier -Date: Thu, 12 Mar 2026 14:08:50 +0000 -Subject: KVM: arm64: Discard PC update state on vcpu reset - -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 -@@ -345,6 +345,20 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu - 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); - } - diff --git a/queue-5.10/series b/queue-5.10/series index 8795dcaf35..66dd8f3625 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -297,6 +297,5 @@ spi-spi-fsl-lpspi-fix-teardown-order-issue-uaf.patch s390-barrier-make-array_index_mask_nospec-__always_inline.patch can-gw-fix-oob-heap-access-in-cgw_csum_crc8_rel.patch cpufreq-conservative-reset-requested_freq-on-limits-change.patch -kvm-arm64-discard-pc-update-state-on-vcpu-reset.patch media-mc-v4l2-serialize-reinit-and-reqbufs-with-req_queue_mutex.patch virtio_net-fix-uaf-on-dst_ops-when-iff_xmit_dst_release-is-cleared-and-napi_tx-is-false.patch diff --git a/queue-5.15/kvm-arm64-discard-pc-update-state-on-vcpu-reset.patch b/queue-5.15/kvm-arm64-discard-pc-update-state-on-vcpu-reset.patch deleted file mode 100644 index 59151e4c80..0000000000 --- a/queue-5.15/kvm-arm64-discard-pc-update-state-on-vcpu-reset.patch +++ /dev/null @@ -1,81 +0,0 @@ -From 1744a6ef48b9a48f017e3e1a0d05de0a6978396e Mon Sep 17 00:00:00 2001 -From: Marc Zyngier -Date: Thu, 12 Mar 2026 14:08:50 +0000 -Subject: KVM: arm64: Discard PC update state on vcpu reset - -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 -@@ -299,6 +299,20 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu - 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); - } - diff --git a/queue-5.15/series b/queue-5.15/series index dce77962d5..b2a29fe4cc 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -369,7 +369,6 @@ s390-syscalls-add-spectre-boundary-for-syscall-dispatch-table.patch s390-barrier-make-array_index_mask_nospec-__always_inline.patch can-gw-fix-oob-heap-access-in-cgw_csum_crc8_rel.patch cpufreq-conservative-reset-requested_freq-on-limits-change.patch -kvm-arm64-discard-pc-update-state-on-vcpu-reset.patch media-mc-v4l2-serialize-reinit-and-reqbufs-with-req_queue_mutex.patch virtio_net-fix-uaf-on-dst_ops-when-iff_xmit_dst_release-is-cleared-and-napi_tx-is-false.patch erofs-add-gfp_noio-in-the-bio-completion-if-needed.patch