Skip to content

Commit 6e68f66

Browse files
committed
KVM: x86: Fix shadow paging use-after-free due to unexpected GFN
jira VULN-186742 cve CVE-2026-46113 commit-author Sean Christopherson <seanjc@google.com> commit 0cb2af2 upstream-diff | Upstream fixes this in kvm_mmu_get_child_sp() and __link_shadow_page(). Neither exists on this tree, so the fix goes into the open-coded interior-SPTE reuse in __direct_map() and FNAME(fetch). An existing interior SPTE is reused only when its child still maps the gfn about to be installed. Otherwise it's dropped and the correct child is installed. The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e, "KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the "wrong" shadow page. However, that was only an imprecision until 2032a93 ("KVM: MMU: Don't allocate gfns page for direct mmu pages") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy. Fixes: 2032a93 ("KVM: MMU: Don't allocate gfns page for direct mmu pages") Fixes: 6aa8b73 ("kvm: userspace interface") Reported-by: Alexander Bulekov <bkov@amazon.com> Reported-by: Fred Griffoul <fgriffo@amazon.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20260503201029.106481-1-pbonzini@redhat.com/ Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 0cb2af2) Signed-off-by: Sultan Alsawaf <sultan@ciq.com>
1 parent cbbe7c6 commit 6e68f66

2 files changed

Lines changed: 34 additions & 31 deletions

File tree

arch/x86/kvm/mmu/mmu.c

Lines changed: 29 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -1169,29 +1169,6 @@ static void drop_spte(struct kvm *kvm, u64 *sptep)
11691169
rmap_remove(kvm, sptep);
11701170
}
11711171

1172-
1173-
static bool __drop_large_spte(struct kvm *kvm, u64 *sptep)
1174-
{
1175-
if (is_large_pte(*sptep)) {
1176-
WARN_ON(sptep_to_sp(sptep)->role.level == PG_LEVEL_4K);
1177-
drop_spte(kvm, sptep);
1178-
--kvm->stat.lpages;
1179-
return true;
1180-
}
1181-
1182-
return false;
1183-
}
1184-
1185-
static void drop_large_spte(struct kvm_vcpu *vcpu, u64 *sptep)
1186-
{
1187-
if (__drop_large_spte(vcpu->kvm, sptep)) {
1188-
struct kvm_mmu_page *sp = sptep_to_sp(sptep);
1189-
1190-
kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn,
1191-
KVM_PAGES_PER_HPAGE(sp->role.level));
1192-
}
1193-
}
1194-
11951172
/*
11961173
* Write-protect on the specified @sptep, @pt_protect indicates whether
11971174
* spte write-protection is caused by protecting shadow page table.
@@ -2312,6 +2289,33 @@ static int mmu_page_zap_pte(struct kvm *kvm, struct kvm_mmu_page *sp,
23122289
return 0;
23132290
}
23142291

2292+
static bool kvm_mmu_child_sp_exists(u64 *sptep, gfn_t gfn)
2293+
{
2294+
struct kvm_mmu_page *child;
2295+
2296+
if (!is_shadow_present_pte(*sptep) || is_large_pte(*sptep))
2297+
return false;
2298+
2299+
child = to_shadow_page(*sptep & PT64_BASE_ADDR_MASK);
2300+
return child && child->gfn == gfn;
2301+
}
2302+
2303+
static void drop_large_spte(struct kvm_vcpu *vcpu, u64 *sptep)
2304+
{
2305+
struct kvm *kvm = vcpu->kvm;
2306+
struct kvm_mmu_page *parent_sp;
2307+
LIST_HEAD(invalid_list);
2308+
2309+
if (!is_shadow_present_pte(*sptep))
2310+
return;
2311+
2312+
parent_sp = sptep_to_sp(sptep);
2313+
WARN_ON_ONCE(parent_sp->role.level == PG_LEVEL_4K);
2314+
2315+
mmu_page_zap_pte(kvm, parent_sp, sptep, &invalid_list);
2316+
kvm_mmu_remote_flush_or_zap(kvm, &invalid_list, true);
2317+
}
2318+
23152319
static int kvm_mmu_page_unlink_children(struct kvm *kvm,
23162320
struct kvm_mmu_page *sp,
23172321
struct list_head *invalid_list)
@@ -2997,10 +3001,10 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t gpa, u32 error_code,
29973001
if (it.level == level)
29983002
break;
29993003

3000-
drop_large_spte(vcpu, it.sptep);
3001-
if (is_shadow_present_pte(*it.sptep))
3004+
if (kvm_mmu_child_sp_exists(it.sptep, base_gfn))
30023005
continue;
30033006

3007+
drop_large_spte(vcpu, it.sptep);
30043008
sp = kvm_mmu_get_page(vcpu, base_gfn, it.addr,
30053009
it.level - 1, true, ACC_ALL);
30063010

arch/x86/kvm/mmu/paging_tmpl.h

Lines changed: 5 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -659,11 +659,11 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gpa_t addr,
659659
gfn_t table_gfn;
660660

661661
clear_sp_write_flooding_count(it.sptep);
662-
drop_large_spte(vcpu, it.sptep);
663662

663+
table_gfn = gw->table_gfn[it.level - 2];
664664
sp = NULL;
665-
if (!is_shadow_present_pte(*it.sptep)) {
666-
table_gfn = gw->table_gfn[it.level - 2];
665+
if (!kvm_mmu_child_sp_exists(it.sptep, table_gfn)) {
666+
drop_large_spte(vcpu, it.sptep);
667667
access = gw->pt_access[it.level - 2];
668668
sp = kvm_mmu_get_page(vcpu, table_gfn, addr,
669669
it.level-1, false, access);
@@ -721,9 +721,8 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, gpa_t addr,
721721

722722
validate_direct_spte(vcpu, it.sptep, direct_access);
723723

724-
drop_large_spte(vcpu, it.sptep);
725-
726-
if (!is_shadow_present_pte(*it.sptep)) {
724+
if (!kvm_mmu_child_sp_exists(it.sptep, base_gfn)) {
725+
drop_large_spte(vcpu, it.sptep);
727726
sp = kvm_mmu_get_page(vcpu, base_gfn, addr,
728727
it.level - 1, true, direct_access);
729728
link_shadow_page(vcpu, it.sptep, sp);

0 commit comments

Comments
 (0)