+++ /dev/null
-From 7258770e5814f15e8308ebda82ac9acf6964ba8e Mon Sep 17 00:00:00 2001
-From: Marc Zyngier <maz@kernel.org>
-Date: Mon, 15 Jun 2026 19:16:25 +0100
-Subject: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling
-
-From: Marc Zyngier <maz@kernel.org>
-
-commit 7258770e5814f15e8308ebda82ac9acf6964ba8e upstream.
-
-Hyunwoo Kim reports some really bad races should the following
-situation occur:
-
-- LPI-I is pending in vcpu-B's AP list
-- vcpu-A writes to vcpu-B's RD to disable its LPIs
-- vcpu-C moves I from B to C
-
-If the last two race nicely enough, vgic_prune_ap_list() can drop
-the irq and AP list locks, reacquire them, and in the interval
-the irq has been freed. UAF follows.
-
-The fix is two-fold:
-
-- Before dropping the irq and ap_list locks, take a reference on
- the irq
-
-- Do not try to handle migration of the pending bit: there is no
- expectation that this state is retained, as per the architecture
-
-With that, we're sure that the interrupt is still around, and we
-safely remove it from the AP list as it has no target at this
-stage (unless another interrupt fires, but that's another story).
-
-Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
-Tested-by: Hyunwoo Kim <imv4bel@gmail.com>
-Link: https://lore.kernel.org/r/ailsCnyoS82r_QRz@v4bel
-Link: https://patch.msgid.link/20260615181625.3029352-1-maz@kernel.org
-Fixes: 5dd4b924e390a ("KVM: arm/arm64: vgic: Add refcounting for IRQs")
-Signed-off-by: Marc Zyngier <maz@kernel.org>
-Cc: stable@vger.kernel.org
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- arch/arm64/kvm/vgic/vgic.c | 9 ++++++++-
- 1 file changed, 8 insertions(+), 1 deletion(-)
-
---- a/arch/arm64/kvm/vgic/vgic.c
-+++ b/arch/arm64/kvm/vgic/vgic.c
-@@ -159,6 +159,7 @@ void vgic_flush_pending_lpis(struct kvm_
- list_for_each_entry_safe(irq, tmp, &vgic_cpu->ap_list_head, ap_list) {
- if (irq->intid >= VGIC_MIN_LPI) {
- raw_spin_lock(&irq->irq_lock);
-+ irq->pending_latch = false;
- list_del(&irq->ap_list);
- irq->vcpu = NULL;
- raw_spin_unlock(&irq->irq_lock);
-@@ -662,7 +663,11 @@ retry:
- continue;
- }
-
-- /* This interrupt looks like it has to be migrated. */
-+ /*
-+ * This interrupt looks like it has to be migrated,
-+ * make sure it is kept alive while locks are dropped.
-+ */
-+ vgic_get_irq_ref(irq);
-
- raw_spin_unlock(&irq->irq_lock);
- raw_spin_unlock(&vgic_cpu->ap_list_lock);
-@@ -707,6 +712,8 @@ retry:
- raw_spin_unlock(&vcpuB->arch.vgic_cpu.ap_list_lock);
- raw_spin_unlock(&vcpuA->arch.vgic_cpu.ap_list_lock);
-
-+ deleted_lpis |= vgic_put_irq_norelease(vcpu->kvm, irq);
-+
- if (target_vcpu_needs_kick) {
- kvm_make_request(KVM_REQ_IRQ_PENDING, target_vcpu);
- kvm_vcpu_kick(target_vcpu);
net-ife-require-eth_hlen-to-be-pullable-in-ife_decode.patch
arm64-dts-qcom-sdm630-describe-adsp_mem-region-properly.patch
kvm-arm64-vgic-check-the-interrupt-is-still-ours-before-migrating-it.patch
-kvm-arm64-vgic-handle-race-between-interrupt-affinity-change-and-lpi-disabling.patch
fbdev-sm712-fix-operator-precedence-in-big_swap-macro.patch
fbdev-radeon-fix-potential-memory-leak-in-radeonfb_pci_register.patch
fbdev-i740fb-fix-potential-memory-leak-in-i740fb_probe.patch
+++ /dev/null
-From 7258770e5814f15e8308ebda82ac9acf6964ba8e Mon Sep 17 00:00:00 2001
-From: Marc Zyngier <maz@kernel.org>
-Date: Mon, 15 Jun 2026 19:16:25 +0100
-Subject: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling
-
-From: Marc Zyngier <maz@kernel.org>
-
-commit 7258770e5814f15e8308ebda82ac9acf6964ba8e upstream.
-
-Hyunwoo Kim reports some really bad races should the following
-situation occur:
-
-- LPI-I is pending in vcpu-B's AP list
-- vcpu-A writes to vcpu-B's RD to disable its LPIs
-- vcpu-C moves I from B to C
-
-If the last two race nicely enough, vgic_prune_ap_list() can drop
-the irq and AP list locks, reacquire them, and in the interval
-the irq has been freed. UAF follows.
-
-The fix is two-fold:
-
-- Before dropping the irq and ap_list locks, take a reference on
- the irq
-
-- Do not try to handle migration of the pending bit: there is no
- expectation that this state is retained, as per the architecture
-
-With that, we're sure that the interrupt is still around, and we
-safely remove it from the AP list as it has no target at this
-stage (unless another interrupt fires, but that's another story).
-
-Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
-Tested-by: Hyunwoo Kim <imv4bel@gmail.com>
-Link: https://lore.kernel.org/r/ailsCnyoS82r_QRz@v4bel
-Link: https://patch.msgid.link/20260615181625.3029352-1-maz@kernel.org
-Fixes: 5dd4b924e390a ("KVM: arm/arm64: vgic: Add refcounting for IRQs")
-Signed-off-by: Marc Zyngier <maz@kernel.org>
-Cc: stable@vger.kernel.org
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- arch/arm64/kvm/vgic/vgic.c | 9 ++++++++-
- 1 file changed, 8 insertions(+), 1 deletion(-)
-
---- a/arch/arm64/kvm/vgic/vgic.c
-+++ b/arch/arm64/kvm/vgic/vgic.c
-@@ -158,6 +158,7 @@ void vgic_flush_pending_lpis(struct kvm_
- list_for_each_entry_safe(irq, tmp, &vgic_cpu->ap_list_head, ap_list) {
- if (irq->intid >= VGIC_MIN_LPI) {
- raw_spin_lock(&irq->irq_lock);
-+ irq->pending_latch = false;
- list_del(&irq->ap_list);
- irq->vcpu = NULL;
- raw_spin_unlock(&irq->irq_lock);
-@@ -661,7 +662,11 @@ retry:
- continue;
- }
-
-- /* This interrupt looks like it has to be migrated. */
-+ /*
-+ * This interrupt looks like it has to be migrated,
-+ * make sure it is kept alive while locks are dropped.
-+ */
-+ vgic_get_irq_ref(irq);
-
- raw_spin_unlock(&irq->irq_lock);
- raw_spin_unlock(&vgic_cpu->ap_list_lock);
-@@ -706,6 +711,8 @@ retry:
- raw_spin_unlock(&vcpuB->arch.vgic_cpu.ap_list_lock);
- raw_spin_unlock(&vcpuA->arch.vgic_cpu.ap_list_lock);
-
-+ deleted_lpis |= vgic_put_irq_norelease(vcpu->kvm, irq);
-+
- if (target_vcpu_needs_kick) {
- kvm_make_request(KVM_REQ_IRQ_PENDING, target_vcpu);
- kvm_vcpu_kick(target_vcpu);
net-ife-require-eth_hlen-to-be-pullable-in-ife_decode.patch
arm64-dts-qcom-sdm630-describe-adsp_mem-region-properly.patch
kvm-arm64-vgic-check-the-interrupt-is-still-ours-before-migrating-it.patch
-kvm-arm64-vgic-handle-race-between-interrupt-affinity-change-and-lpi-disabling.patch
fbdev-metronomefb-fix-potential-memory-leak-in-metronomefb_probe.patch
fbdev-broadsheetfb-fix-potential-memory-leak-in-broadsheetfb_probe.patch
fbdev-hecubafb-fix-potential-memory-leak-in-hecubafb_probe.patch
+++ /dev/null
-From 7258770e5814f15e8308ebda82ac9acf6964ba8e Mon Sep 17 00:00:00 2001
-From: Marc Zyngier <maz@kernel.org>
-Date: Mon, 15 Jun 2026 19:16:25 +0100
-Subject: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling
-
-From: Marc Zyngier <maz@kernel.org>
-
-commit 7258770e5814f15e8308ebda82ac9acf6964ba8e upstream.
-
-Hyunwoo Kim reports some really bad races should the following
-situation occur:
-
-- LPI-I is pending in vcpu-B's AP list
-- vcpu-A writes to vcpu-B's RD to disable its LPIs
-- vcpu-C moves I from B to C
-
-If the last two race nicely enough, vgic_prune_ap_list() can drop
-the irq and AP list locks, reacquire them, and in the interval
-the irq has been freed. UAF follows.
-
-The fix is two-fold:
-
-- Before dropping the irq and ap_list locks, take a reference on
- the irq
-
-- Do not try to handle migration of the pending bit: there is no
- expectation that this state is retained, as per the architecture
-
-With that, we're sure that the interrupt is still around, and we
-safely remove it from the AP list as it has no target at this
-stage (unless another interrupt fires, but that's another story).
-
-Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
-Tested-by: Hyunwoo Kim <imv4bel@gmail.com>
-Link: https://lore.kernel.org/r/ailsCnyoS82r_QRz@v4bel
-Link: https://patch.msgid.link/20260615181625.3029352-1-maz@kernel.org
-Fixes: 5dd4b924e390a ("KVM: arm/arm64: vgic: Add refcounting for IRQs")
-Signed-off-by: Marc Zyngier <maz@kernel.org>
-Cc: stable@vger.kernel.org
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- arch/arm64/kvm/vgic/vgic.c | 9 ++++++++-
- 1 file changed, 8 insertions(+), 1 deletion(-)
-
---- a/arch/arm64/kvm/vgic/vgic.c
-+++ b/arch/arm64/kvm/vgic/vgic.c
-@@ -160,6 +160,7 @@ void vgic_flush_pending_lpis(struct kvm_
- list_for_each_entry_safe(irq, tmp, &vgic_cpu->ap_list_head, ap_list) {
- if (irq->intid >= VGIC_MIN_LPI) {
- raw_spin_lock(&irq->irq_lock);
-+ irq->pending_latch = false;
- list_del(&irq->ap_list);
- irq->vcpu = NULL;
- raw_spin_unlock(&irq->irq_lock);
-@@ -663,7 +664,11 @@ retry:
- continue;
- }
-
-- /* This interrupt looks like it has to be migrated. */
-+ /*
-+ * This interrupt looks like it has to be migrated,
-+ * make sure it is kept alive while locks are dropped.
-+ */
-+ vgic_get_irq_ref(irq);
-
- raw_spin_unlock(&irq->irq_lock);
- raw_spin_unlock(&vgic_cpu->ap_list_lock);
-@@ -708,6 +713,8 @@ retry:
- raw_spin_unlock(&vcpuB->arch.vgic_cpu.ap_list_lock);
- raw_spin_unlock(&vcpuA->arch.vgic_cpu.ap_list_lock);
-
-+ deleted_lpis |= vgic_put_irq_norelease(vcpu->kvm, irq);
-+
- if (target_vcpu_needs_kick) {
- kvm_make_request(KVM_REQ_IRQ_PENDING, target_vcpu);
- kvm_vcpu_kick(target_vcpu);
arm64-dts-qcom-sdm630-describe-adsp_mem-region-properly.patch
kvm-s390-pci-fix-gisc-refcount-leak-on-aif-enable-failure.patch
kvm-arm64-vgic-check-the-interrupt-is-still-ours-before-migrating-it.patch
-kvm-arm64-vgic-handle-race-between-interrupt-affinity-change-and-lpi-disabling.patch
kvm-s390-pci-fix-handling-of-aif-enable-without-aisb.patch
kvm-x86-ignore-pending-pv-eoi-if-the-vcpu-has-since-disabled-pv-eois.patch
fbdev-metronomefb-fix-potential-memory-leak-in-metronomefb_probe.patch
+++ /dev/null
-From 7258770e5814f15e8308ebda82ac9acf6964ba8e Mon Sep 17 00:00:00 2001
-From: Marc Zyngier <maz@kernel.org>
-Date: Mon, 15 Jun 2026 19:16:25 +0100
-Subject: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling
-
-From: Marc Zyngier <maz@kernel.org>
-
-commit 7258770e5814f15e8308ebda82ac9acf6964ba8e upstream.
-
-Hyunwoo Kim reports some really bad races should the following
-situation occur:
-
-- LPI-I is pending in vcpu-B's AP list
-- vcpu-A writes to vcpu-B's RD to disable its LPIs
-- vcpu-C moves I from B to C
-
-If the last two race nicely enough, vgic_prune_ap_list() can drop
-the irq and AP list locks, reacquire them, and in the interval
-the irq has been freed. UAF follows.
-
-The fix is two-fold:
-
-- Before dropping the irq and ap_list locks, take a reference on
- the irq
-
-- Do not try to handle migration of the pending bit: there is no
- expectation that this state is retained, as per the architecture
-
-With that, we're sure that the interrupt is still around, and we
-safely remove it from the AP list as it has no target at this
-stage (unless another interrupt fires, but that's another story).
-
-Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
-Tested-by: Hyunwoo Kim <imv4bel@gmail.com>
-Link: https://lore.kernel.org/r/ailsCnyoS82r_QRz@v4bel
-Link: https://patch.msgid.link/20260615181625.3029352-1-maz@kernel.org
-Fixes: 5dd4b924e390a ("KVM: arm/arm64: vgic: Add refcounting for IRQs")
-Signed-off-by: Marc Zyngier <maz@kernel.org>
-Cc: stable@vger.kernel.org
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- arch/arm64/kvm/vgic/vgic.c | 9 ++++++++-
- 1 file changed, 8 insertions(+), 1 deletion(-)
-
---- a/arch/arm64/kvm/vgic/vgic.c
-+++ b/arch/arm64/kvm/vgic/vgic.c
-@@ -144,6 +144,7 @@ void vgic_flush_pending_lpis(struct kvm_
- list_for_each_entry_safe(irq, tmp, &vgic_cpu->ap_list_head, ap_list) {
- if (irq->intid >= VGIC_MIN_LPI) {
- raw_spin_lock(&irq->irq_lock);
-+ irq->pending_latch = false;
- list_del(&irq->ap_list);
- irq->vcpu = NULL;
- raw_spin_unlock(&irq->irq_lock);
-@@ -661,7 +662,11 @@ retry:
- continue;
- }
-
-- /* This interrupt looks like it has to be migrated. */
-+ /*
-+ * This interrupt looks like it has to be migrated,
-+ * make sure it is kept alive while locks are dropped.
-+ */
-+ vgic_get_irq_ref(irq);
-
- raw_spin_unlock(&irq->irq_lock);
- raw_spin_unlock(&vgic_cpu->ap_list_lock);
-@@ -706,6 +711,8 @@ retry:
- raw_spin_unlock(&vcpuB->arch.vgic_cpu.ap_list_lock);
- raw_spin_unlock(&vcpuA->arch.vgic_cpu.ap_list_lock);
-
-+ deleted_lpis |= vgic_put_irq_norelease(vcpu->kvm, irq);
-+
- if (target_vcpu_needs_kick) {
- kvm_make_request(KVM_REQ_IRQ_PENDING, target_vcpu);
- kvm_vcpu_kick(target_vcpu);
loongarch-kvm-return-full-old-csr-value-from-kvm_emu_xchg_csr.patch
kvm-s390-pci-fix-gisc-refcount-leak-on-aif-enable-failure.patch
kvm-arm64-vgic-check-the-interrupt-is-still-ours-before-migrating-it.patch
-kvm-arm64-vgic-handle-race-between-interrupt-affinity-change-and-lpi-disabling.patch
kvm-s390-pci-fix-handling-of-aif-enable-without-aisb.patch
kvm-sev-do-not-allow-intra-host-migration-mirroring-of-snp-vms.patch
kvm-x86-ignore-pending-pv-eoi-if-the-vcpu-has-since-disabled-pv-eois.patch
+++ /dev/null
-From 7258770e5814f15e8308ebda82ac9acf6964ba8e Mon Sep 17 00:00:00 2001
-From: Marc Zyngier <maz@kernel.org>
-Date: Mon, 15 Jun 2026 19:16:25 +0100
-Subject: KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling
-
-From: Marc Zyngier <maz@kernel.org>
-
-commit 7258770e5814f15e8308ebda82ac9acf6964ba8e upstream.
-
-Hyunwoo Kim reports some really bad races should the following
-situation occur:
-
-- LPI-I is pending in vcpu-B's AP list
-- vcpu-A writes to vcpu-B's RD to disable its LPIs
-- vcpu-C moves I from B to C
-
-If the last two race nicely enough, vgic_prune_ap_list() can drop
-the irq and AP list locks, reacquire them, and in the interval
-the irq has been freed. UAF follows.
-
-The fix is two-fold:
-
-- Before dropping the irq and ap_list locks, take a reference on
- the irq
-
-- Do not try to handle migration of the pending bit: there is no
- expectation that this state is retained, as per the architecture
-
-With that, we're sure that the interrupt is still around, and we
-safely remove it from the AP list as it has no target at this
-stage (unless another interrupt fires, but that's another story).
-
-Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
-Tested-by: Hyunwoo Kim <imv4bel@gmail.com>
-Link: https://lore.kernel.org/r/ailsCnyoS82r_QRz@v4bel
-Link: https://patch.msgid.link/20260615181625.3029352-1-maz@kernel.org
-Fixes: 5dd4b924e390a ("KVM: arm/arm64: vgic: Add refcounting for IRQs")
-Signed-off-by: Marc Zyngier <maz@kernel.org>
-Cc: stable@vger.kernel.org
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
- arch/arm64/kvm/vgic/vgic.c | 9 ++++++++-
- 1 file changed, 8 insertions(+), 1 deletion(-)
-
---- a/arch/arm64/kvm/vgic/vgic.c
-+++ b/arch/arm64/kvm/vgic/vgic.c
-@@ -160,6 +160,7 @@ void vgic_flush_pending_lpis(struct kvm_
- list_for_each_entry_safe(irq, tmp, &vgic_cpu->ap_list_head, ap_list) {
- if (irq->intid >= VGIC_MIN_LPI) {
- raw_spin_lock(&irq->irq_lock);
-+ irq->pending_latch = false;
- list_del(&irq->ap_list);
- irq->vcpu = NULL;
- raw_spin_unlock(&irq->irq_lock);
-@@ -678,7 +679,11 @@ retry:
- continue;
- }
-
-- /* This interrupt looks like it has to be migrated. */
-+ /*
-+ * This interrupt looks like it has to be migrated,
-+ * make sure it is kept alive while locks are dropped.
-+ */
-+ vgic_get_irq_ref(irq);
-
- raw_spin_unlock(&irq->irq_lock);
- raw_spin_unlock(&vgic_cpu->ap_list_lock);
-@@ -723,6 +728,8 @@ retry:
- raw_spin_unlock(&vcpuB->arch.vgic_cpu.ap_list_lock);
- raw_spin_unlock(&vcpuA->arch.vgic_cpu.ap_list_lock);
-
-+ deleted_lpis |= vgic_put_irq_norelease(vcpu->kvm, irq);
-+
- if (target_vcpu_needs_kick) {
- kvm_make_request(KVM_REQ_IRQ_PENDING, target_vcpu);
- kvm_vcpu_kick(target_vcpu);
arm64-dts-qcom-sdm630-describe-adsp_mem-region-properly.patch
kvm-s390-pci-fix-gisc-refcount-leak-on-aif-enable-failure.patch
kvm-arm64-vgic-check-the-interrupt-is-still-ours-before-migrating-it.patch
-kvm-arm64-vgic-handle-race-between-interrupt-affinity-change-and-lpi-disabling.patch
kvm-s390-pci-fix-handling-of-aif-enable-without-aisb.patch
kvm-x86-ignore-pending-pv-eoi-if-the-vcpu-has-since-disabled-pv-eois.patch
fbdev-metronomefb-fix-potential-memory-leak-in-metronomefb_probe.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
