From 86a24feec1919b7858bb1062d5160f0e12aa5c7d Mon Sep 17 00:00:00 2001 From: Sean Christopherson Date: Wed, 23 Sep 2026 08:51:06 -0700 Subject: [PATCH 1/5] KVM: SVM: Add paranoid helper for checking if vCPU is AVIC-addressable Add a helper to check if a vCPU is addressable by AVIC hardware, i.e. has an APIC ID that fits in the physical ID table, and use the more paranoid helper when determining if a vCPU is compatible with AVIC when initializing the vCPU. KVM is supposed to reject vCPU creation if the vCPU's ID is greater than or equal to max_vcpu_ids, i.e. simply checking the architectural maximum *should* suffice. But piecing together why this is safe is unnecessarily difficult, and there is no meaningful downside to being extra cautious. Suggested-by: Naveen N Rao (AMD) Reviewed-by: Naveen N Rao (AMD) Link: https://patch.msgid.link/20260923155108.1550622-2-seanjc@google.com Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/avic.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 3b037e385523..0e4b5eb6ac82 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -395,6 +395,11 @@ static phys_addr_t avic_get_backing_page_address(struct vcpu_svm *svm) return __sme_set(__pa(svm->vcpu.arch.apic->regs)); } +static bool avic_is_addressable_vcpu(struct kvm_vcpu *vcpu) +{ + return vcpu->vcpu_id <= __avic_get_max_physical_id(vcpu->kvm, NULL); +} + void avic_init_vmcb(struct vcpu_svm *svm, struct vmcb *vmcb) { struct kvm_svm *kvm_svm = to_kvm_svm(svm->vcpu.kvm); @@ -412,7 +417,6 @@ void avic_init_vmcb(struct vcpu_svm *svm, struct vmcb *vmcb) static int avic_init_backing_page(struct kvm_vcpu *vcpu) { - u32 max_id = x2avic_enabled ? x2avic_max_physical_id : AVIC_MAX_PHYSICAL_ID; struct kvm_svm *kvm_svm = to_kvm_svm(vcpu->kvm); struct vcpu_svm *svm = to_svm(vcpu); u32 id = vcpu->vcpu_id; @@ -425,7 +429,7 @@ static int avic_init_backing_page(struct kvm_vcpu *vcpu) * avic_vcpu_load() expects to be called if and only if the vCPU has * fully initialized AVIC. */ - if (id > max_id) { + if (!avic_is_addressable_vcpu(vcpu)) { kvm_set_apicv_inhibit(vcpu->kvm, APICV_INHIBIT_REASON_PHYSICAL_ID_TOO_BIG); vcpu->arch.apic->apicv_active = false; return 0; From 12e0d427c335f6f140087def6b2002419ee5f6b0 Mon Sep 17 00:00:00 2001 From: Sean Christopherson Date: Wed, 23 Sep 2026 08:51:07 -0700 Subject: [PATCH 2/5] KVM: SVM: Use "is AVIC-addressable" helper to sanity check load()/put() Use avic_is_addressable_vcpu() instead of open coding a check on the bounds of the allocated table for the sanity checks when loading/putting AVIC state for a vCPU. If KVM botches the allocation, then KVM will already have performed an OOB write in avic_init_backing_page(), i.e. being super paranoid in load()/put() doesn't provide meaningful protection in practice. Cc: Naveen N Rao (AMD) Reviewed-by: Naveen N Rao (AMD) Link: https://patch.msgid.link/20260923155108.1550622-3-seanjc@google.com Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/avic.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 0e4b5eb6ac82..4173a30dfe60 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -1049,8 +1049,7 @@ static void __avic_vcpu_load(struct kvm_vcpu *vcpu, int cpu, if (WARN_ON(h_physical_id & ~AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK)) return; - if (WARN_ON_ONCE(vcpu->vcpu_id * sizeof(entry) >= - PAGE_SIZE << avic_get_physical_id_table_order(vcpu->kvm))) + if (WARN_ON_ONCE(!avic_is_addressable_vcpu(vcpu))) return; /* @@ -1112,8 +1111,7 @@ static void __avic_vcpu_put(struct kvm_vcpu *vcpu, enum avic_vcpu_action action) lockdep_assert_preemption_disabled(); - if (WARN_ON_ONCE(vcpu->vcpu_id * sizeof(entry) >= - PAGE_SIZE << avic_get_physical_id_table_order(vcpu->kvm))) + if (WARN_ON_ONCE(!avic_is_addressable_vcpu(vcpu))) return; /* From 88c15bbd43ae95a2c81f3f21a7fd8f4fb0914902 Mon Sep 17 00:00:00 2001 From: "Naveen N Rao (AMD)" Date: Wed, 23 Sep 2026 08:51:08 -0700 Subject: [PATCH 3/5] KVM: SVM: Clear AVIC Physical ID table entry if vCPU creation fails If vCPU creation fails after kvm_arch_vcpu_create(), the AVIC Physical ID table entry corresponding to that vCPU continues to point to the freed APIC backing page which can result in UAF. Address this by clearing out the corresponding AVIC Physical ID table entry in the vcpu_free() callback, similar to the VMX commit b41f2ca6c060 ("KVM: VMX: Fix stale PID-pointer table entry left after vCPU free"). Though unlikely, it is also possible that svm_vcpu_create() itself fails after the AVIC Physical ID table entry has been setup if memory allocation fails in svm_vcpu_alloc_msrpm(). Clear the entry in this path as well. Note: this change depends on commit 97d65b544f48 ("KVM: Check for duplicate vcpu_id as early as possible"), which ensures that a vCPU with a duplicate ID is never created. Otherwise, a valid AVIC Physical ID table entry for an existing vCPU will be cleared. Fixes: 44a95dae1d22 ("KVM: x86: Detect and Initialize AVIC support") Signed-off-by: Naveen N Rao (AMD) Tested-by: Atish Patra [sean: use avic_is_addressable_vcpu()] Link: https://patch.msgid.link/20260923155108.1550622-4-seanjc@google.com Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/avic.c | 8 ++++++++ arch/x86/kvm/svm/svm.c | 6 +++++- arch/x86/kvm/svm/svm.h | 1 + 3 files changed, 14 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 4173a30dfe60..96ca39c0045f 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -889,6 +889,14 @@ int avic_init_vcpu(struct vcpu_svm *svm) return ret; } +void avic_vcpu_free(struct kvm_vcpu *vcpu) +{ + struct kvm_svm *kvm_svm = to_kvm_svm(vcpu->kvm); + + if (kvm_svm->avic_physical_id_table && avic_is_addressable_vcpu(vcpu)) + WRITE_ONCE(kvm_svm->avic_physical_id_table[vcpu->vcpu_id], 0); +} + void avic_apicv_post_state_restore(struct kvm_vcpu *vcpu) { avic_handle_dfr_update(vcpu); diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index fe0cba4731b2..c054803d4673 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -1328,7 +1328,7 @@ static int svm_vcpu_create(struct kvm_vcpu *vcpu) svm->msrpm = svm_vcpu_alloc_msrpm(); if (!svm->msrpm) { err = -ENOMEM; - goto error_free_sev; + goto error_free_avic; } svm->x2avic_msrs_intercepted = true; @@ -1342,6 +1342,8 @@ static int svm_vcpu_create(struct kvm_vcpu *vcpu) return 0; +error_free_avic: + avic_vcpu_free(vcpu); error_free_sev: sev_free_vcpu(vcpu); error_free_vmcb_page: @@ -1356,6 +1358,8 @@ static void svm_vcpu_free(struct kvm_vcpu *vcpu) WARN_ON_ONCE(!list_empty(&svm->ir_list)); + avic_vcpu_free(vcpu); + svm_leave_nested(vcpu); svm_free_nested(svm); diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h index 84f19026d3e8..29bde741874a 100644 --- a/arch/x86/kvm/svm/svm.h +++ b/arch/x86/kvm/svm/svm.h @@ -955,6 +955,7 @@ void avic_init_vmcb(struct vcpu_svm *svm, struct vmcb *vmcb); int avic_incomplete_ipi_interception(struct kvm_vcpu *vcpu); int avic_unaccelerated_access_interception(struct kvm_vcpu *vcpu); int avic_init_vcpu(struct vcpu_svm *svm); +void avic_vcpu_free(struct kvm_vcpu *vcpu); void avic_vcpu_load(struct kvm_vcpu *vcpu, int cpu); void avic_vcpu_put(struct kvm_vcpu *vcpu); void avic_apicv_post_state_restore(struct kvm_vcpu *vcpu); From 97818b2fa7082e940ddd36dab12a68615300e798 Mon Sep 17 00:00:00 2001 From: Jann Horn Date: Mon, 10 Aug 2026 17:33:59 +0200 Subject: [PATCH 4/5] KVM: SEV: Fix page dirtying in sev_gmem_post_populate() set_page_dirty() requires that the caller holds some kind of lock to ensure that the page's mapping does not concurrently go away. That is not the case for a random page we got from get_user_pages_fast(), so use set_page_dirty_lock(). Fixes: 97cd21d57e9b ("KVM: SEV: Mark source page dirty when writing back CPUID data on failure") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260810-x86-kvm-setpagedirty-v1-1-85f180892d4f@google.com [sean: tag for stable] Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/sev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 0c1ebb16cec6..d24dbe633b11 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -2421,7 +2421,7 @@ static int sev_gmem_post_populate(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn, void *dst_vaddr = kmap_local_pfn(pfn); memcpy(src_vaddr, dst_vaddr, PAGE_SIZE); - set_page_dirty(src_page); + set_page_dirty_lock(src_page); kunmap_local(dst_vaddr); kunmap_local(src_vaddr); From b3e6212dea2e4328a841ceb37f377583176dc735 Mon Sep 17 00:00:00 2001 From: Jinu Kim Date: Fri, 7 Aug 2026 20:28:18 +0900 Subject: [PATCH 5/5] KVM: x86: Use active memslots for the per-vCPU MMIO cache KVM tags the per-vCPU MMIO cache with a memslot generation so that a memslot update invalidates cached MMIO information. Both the fill and validation paths use kvm_memslots(), which unconditionally selects address space 0, even when the vCPU is running in SMM and using address space 1. Commit 56f17dd3fbc4 ("kvm: x86: fix stale mmio cache bug") added the memslot generation to the cache key so that a memslot update could not leave a stale entry valid. When commit 699023e23965 ("KVM: x86: add SMM to the MMU role, support SMRAM address space") added the SMM address space, these helpers were not converted to use the active memslots. Consequently, an update to the SMM memslots can leave an entry from the old SMM address space apparently valid after the vCPU returns to the normal address space. A guest can then cause an access to valid RAM at the same GFN to be returned to userspace as KVM_EXIT_MMIO. Completing that exit through the VMM's RAM address space writes the backing page without going through KVM's write-tracking path. If the page backs a nested EPT table, KVM can continue using shadow translations derived from the old contents. The WARN_ON_ONCE() in kvm_mmu_write_protect_fault() catches this invalid cache and memslot combination. Use the vCPU's active memslots when caching and validating the entry. Memslot generations are unique across address spaces, so the generation also distinguishes the normal and SMM views. This matches the MMIO SPTE cache, which already uses kvm_vcpu_memslots(). On an unpatched current-mainline kernel, a regression test that fills the cache in SMM and updates only the SMM memslots fails the intended RAM write and triggers the kvm_mmu_write_protect_fault() warning. With this change, the same test completes the RAM write without a warning. The x86/smm_test, set_memory_region_test, and memslot_modification_stress_test selftests also pass. Fixes: 699023e23965 ("KVM: x86: add SMM to the MMU role, support SMRAM address space") Cc: stable@vger.kernel.org Signed-off-by: Jinu Kim Link: https://patch.msgid.link/20260807112818.958190-1-kimjw04271234@gmail.com Signed-off-by: Sean Christopherson --- arch/x86/kvm/x86.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h index 0f5919b092e4..f72897ae56bc 100644 --- a/arch/x86/kvm/x86.h +++ b/arch/x86/kvm/x86.h @@ -250,7 +250,7 @@ static inline bool is_noncanonical_invlpg_address(u64 la, struct kvm_vcpu *vcpu) static inline void vcpu_cache_mmio_info(struct kvm_vcpu *vcpu, gva_t gva, gfn_t gfn, unsigned access) { - u64 gen = kvm_memslots(vcpu->kvm)->generation; + u64 gen = kvm_vcpu_memslots(vcpu)->generation; if (unlikely(gen & KVM_MEMSLOT_GEN_UPDATE_IN_PROGRESS)) return; @@ -267,7 +267,7 @@ static inline void vcpu_cache_mmio_info(struct kvm_vcpu *vcpu, static inline bool vcpu_match_mmio_gen(struct kvm_vcpu *vcpu) { - return vcpu->arch.mmio_gen == kvm_memslots(vcpu->kvm)->generation; + return vcpu->arch.mmio_gen == kvm_vcpu_memslots(vcpu)->generation; } /*