[ciqlts9_2] Multiple patches tested (2 commits)#1408
Conversation
jira VULN-186744 cve CVE-2026-46113 commit-author Sean Christopherson <seanjc@google.com> commit 0cb2af2 upstream-diff | Two adaptations were required for this tree: 1. spte_to_child_sp() does not exist here. Applying the upstream fix verbatim failed to build ("implicit declaration of function 'spte_to_child_sp'", -Werror). That helper was introduced upstream by 285f646 ("KVM: x86/mmu: Add helper to convert SPTE value to its shadow page"), an unrelated helper-relocation refactor that does not apply cleanly here; rather than pull it in, the call is written using this tree's existing equivalent. spte_to_child_sp(x) is defined upstream as to_shadow_page(x & SPTE_BASE_ADDR_MASK), which this tree already uses verbatim, so the substitution is functionally identical. 2. The upstream commit deletes drop_large_spte(), converting its sole caller to mmu_page_zap_pte() in __link_shadow_page(). This tree's drop_large_spte() differs cosmetically (WARN_ON / kvm_flush_remote_tlbs_with_address() vs the later WARN_ON_ONCE / kvm_flush_remote_tlbs_sptep() forms), so the deletion hunk did not apply automatically; the function is removed by hand. The caller conversion applied cleanly and no other references remain. No functional difference from upstream. 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: Shreeya Patel <spatel@ciq.com>
jira VULN-191428 cve CVE-2026-53359 commit-author Paolo Bonzini <pbonzini@redhat.com> commit 81ccda3 upstream-diff | spte_to_child_sp() does not exist in this tree; the upstream condition spte_to_child_sp(*sptep) is written using this tree's equivalent to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK). See the prerequisite "unexpected GFN" commit for the full rationale. Functionally identical to upstream. Commit 0cb2af2 ("KVM: x86: Fix shadow paging use-after-free due to unexpected GFN") fixed a shadow paging mismatch between stored and computed GFNs; the bug could be triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. The rmap_remove() call would miss entries created after the PDE change because the GFN of the leaf SPTE does not match the GFN of the struct kvm_mmu_page. A similar hole however remains if the modified PDE points to a non-leaf page. In this case the gfn can be made to match, but the role does not match: the original large 2MB page creates a kvm_mmu_page with direct=1, while the new 4KB needs a kvm_mmu_page with direct=0. However, kvm_mmu_get_child_sp() does not compare the role, and therefore reuses the page. The next step is installing a leaf (4KB) SPTE on the new path which records an rmap entry under the gfn resolved by the walk. But when that child is zapped its parent kvm_mmu_page has direct=1 and kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as sp->gfn + index instead of using sp->shadowed_translation[] (or sp->gfns[] in older kernels). It therefore fails to remove the recorded entry. When the memslot is dropped the shadow page is freed but the rmap entry survives, as in the scenario that was already fixed. Code that later walks that gfn (dirty logging, MMU notifier invalidation, and so on) dereferences an sptep that lies in the freed page, causing the use-after-free. Fixes: 2032a93 ("KVM: MMU: Don't allocate gfns page for direct mmu pages") Reported-by: Hyunwoo Kim <imv4bel@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 81ccda3) Signed-off-by: Shreeya Patel <spatel@ciq.com>
|
🤖 Validation Checks In Progress Workflow run: https://github.com/ctrliq/kernel-src-tree/actions/runs/28817353824 |
🔍 Interdiff Analysis
================================================================================
* DELTA DIFFERENCES - code changes that differ between the patches *
================================================================================
--- b/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -1148,6 +1148,20 @@
rmap_remove(kvm, sptep);
}
+static void drop_large_spte(struct kvm *kvm, u64 *sptep, bool flush)
+{
+ struct kvm_mmu_page *sp;
+
+ sp = sptep_to_sp(sptep);
+ WARN_ON(sp->role.level == PG_LEVEL_4K);
+
+ drop_spte(kvm, sptep);
+
+ if (flush)
+ kvm_flush_remote_tlbs_with_address(kvm, sp->gfn,
+ KVM_PAGES_PER_HPAGE(sp->role.level));
+}
+
/*
* Write-protect on the specified @sptep, @pt_protect indicates whether
* spte write-protection is caused by protecting shadow page table.
@@ -2220,7 +2234,7 @@
union kvm_mmu_page_role role;
if (is_shadow_present_pte(*sptep) && !is_large_pte(*sptep) &&
- to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK) && to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK)->gfn == gfn)
+ spte_to_child_sp(*sptep) && spte_to_child_sp(*sptep)->gfn == gfn)
return ERR_PTR(-EEXIST);
role = kvm_mmu_child_role(sptep, direct, access);
################################################################################
! REJECTED PATCH2 HUNKS - could not be compared; manual review needed !
################################################################################
--- b/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -1289,19 +1291,6 @@
rmap_remove(kvm, sptep);
}
-static void drop_large_spte(struct kvm *kvm, u64 *sptep, bool flush)
-{
- struct kvm_mmu_page *sp;
-
- sp = sptep_to_sp(sptep);
- WARN_ON_ONCE(sp->role.level == PG_LEVEL_4K);
-
- drop_spte(kvm, sptep);
-
- if (flush)
- kvm_flush_remote_tlbs_sptep(kvm, sptep);
-}
-
/*
* Write-protect on the specified @sptep, @pt_protect indicates whether
* spte write-protection is caused by protecting shadow page table.
================================================================================
* CONTEXT DIFFERENCES - surrounding code differences between the patches *
================================================================================
--- b/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -1151,13 +1292,12 @@
struct kvm_mmu_page *sp;
sp = sptep_to_sp(sptep);
- WARN_ON(sp->role.level == PG_LEVEL_4K);
+ WARN_ON_ONCE(sp->role.level == PG_LEVEL_4K);
drop_spte(kvm, sptep);
if (flush)
- kvm_flush_remote_tlbs_with_address(kvm, sp->gfn,
- KVM_PAGES_PER_HPAGE(sp->role.level));
+ kvm_flush_remote_tlbs_sptep(kvm, sptep);
}
/*
================================================================================
* DELTA DIFFERENCES - code changes that differ between the patches *
================================================================================
--- b/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -2219,11 +2219,8 @@
{
union kvm_mmu_page_role role = kvm_mmu_child_role(sptep, direct, access);
- if (is_shadow_present_pte(*sptep) &&
- !is_large_pte(*sptep) &&
- to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK) &&
- to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK)->gfn == gfn &&
- to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK)->role.word == role.word)
+ if (is_shadow_present_pte(*sptep) && !is_large_pte(*sptep) &&
+ to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK) && to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK)->gfn == gfn)
return ERR_PTR(-EEXIST);
return kvm_mmu_get_shadow_page(vcpu, gfn, role);
################################################################################
! REJECTED PATCH2 HUNKS - could not be compared; manual review needed !
################################################################################
--- b/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -2461,8 +2461,11 @@
{
union kvm_mmu_page_role role;
- if (is_shadow_present_pte(*sptep) && !is_large_pte(*sptep) &&
- spte_to_child_sp(*sptep) && spte_to_child_sp(*sptep)->gfn == gfn)
+ if (is_shadow_present_pte(*sptep) &&
+ !is_large_pte(*sptep) &&
+ spte_to_child_sp(*sptep) &&
+ spte_to_child_sp(*sptep)->gfn == gfn &&
+ spte_to_child_sp(*sptep)->role.word == role.word)
return ERR_PTR(-EEXIST);
role = kvm_mmu_child_role(sptep, direct, access);
================================================================================
* CONTEXT DIFFERENCES - surrounding code differences between the patches *
================================================================================
--- b/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -2217,7 +2217,7 @@
union kvm_mmu_page_role role;
if (is_shadow_present_pte(*sptep) && !is_large_pte(*sptep) &&
- to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK) && to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK)->gfn == gfn)
+ spte_to_child_sp(*sptep) && spte_to_child_sp(*sptep)->gfn == gfn)
return ERR_PTR(-EEXIST);
role = kvm_mmu_child_role(sptep, direct, access);This is an automated interdiff check for backported commits. |
JIRA PR Check Results2 commit(s) with issues found: Commit
|
|
❌ Validation checks completed with issues View full results: https://github.com/ctrliq/kernel-src-tree/actions/runs/28817353824 |
|
🤖 Validation Checks In Progress Workflow run: https://github.com/ctrliq/kernel-src-tree/actions/runs/28822279125 |
🔍 Interdiff Analysis
================================================================================
* DELTA DIFFERENCES - code changes that differ between the patches *
================================================================================
--- b/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -1148,6 +1148,20 @@
rmap_remove(kvm, sptep);
}
+static void drop_large_spte(struct kvm *kvm, u64 *sptep, bool flush)
+{
+ struct kvm_mmu_page *sp;
+
+ sp = sptep_to_sp(sptep);
+ WARN_ON(sp->role.level == PG_LEVEL_4K);
+
+ drop_spte(kvm, sptep);
+
+ if (flush)
+ kvm_flush_remote_tlbs_with_address(kvm, sp->gfn,
+ KVM_PAGES_PER_HPAGE(sp->role.level));
+}
+
/*
* Write-protect on the specified @sptep, @pt_protect indicates whether
* spte write-protection is caused by protecting shadow page table.
@@ -2220,7 +2234,7 @@
union kvm_mmu_page_role role;
if (is_shadow_present_pte(*sptep) && !is_large_pte(*sptep) &&
- to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK) && to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK)->gfn == gfn)
+ spte_to_child_sp(*sptep) && spte_to_child_sp(*sptep)->gfn == gfn)
return ERR_PTR(-EEXIST);
role = kvm_mmu_child_role(sptep, direct, access);
################################################################################
! REJECTED PATCH2 HUNKS - could not be compared; manual review needed !
################################################################################
--- b/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -1289,19 +1291,6 @@
rmap_remove(kvm, sptep);
}
-static void drop_large_spte(struct kvm *kvm, u64 *sptep, bool flush)
-{
- struct kvm_mmu_page *sp;
-
- sp = sptep_to_sp(sptep);
- WARN_ON_ONCE(sp->role.level == PG_LEVEL_4K);
-
- drop_spte(kvm, sptep);
-
- if (flush)
- kvm_flush_remote_tlbs_sptep(kvm, sptep);
-}
-
/*
* Write-protect on the specified @sptep, @pt_protect indicates whether
* spte write-protection is caused by protecting shadow page table.
================================================================================
* CONTEXT DIFFERENCES - surrounding code differences between the patches *
================================================================================
--- b/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -1151,13 +1292,12 @@
struct kvm_mmu_page *sp;
sp = sptep_to_sp(sptep);
- WARN_ON(sp->role.level == PG_LEVEL_4K);
+ WARN_ON_ONCE(sp->role.level == PG_LEVEL_4K);
drop_spte(kvm, sptep);
if (flush)
- kvm_flush_remote_tlbs_with_address(kvm, sp->gfn,
- KVM_PAGES_PER_HPAGE(sp->role.level));
+ kvm_flush_remote_tlbs_sptep(kvm, sptep);
}
/*
================================================================================
* DELTA DIFFERENCES - code changes that differ between the patches *
================================================================================
--- b/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -2219,11 +2219,8 @@
{
union kvm_mmu_page_role role = kvm_mmu_child_role(sptep, direct, access);
- if (is_shadow_present_pte(*sptep) &&
- !is_large_pte(*sptep) &&
- to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK) &&
- to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK)->gfn == gfn &&
- to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK)->role.word == role.word)
+ if (is_shadow_present_pte(*sptep) && !is_large_pte(*sptep) &&
+ to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK) && to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK)->gfn == gfn)
return ERR_PTR(-EEXIST);
return kvm_mmu_get_shadow_page(vcpu, gfn, role);
################################################################################
! REJECTED PATCH2 HUNKS - could not be compared; manual review needed !
################################################################################
--- b/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -2461,8 +2461,11 @@
{
union kvm_mmu_page_role role;
- if (is_shadow_present_pte(*sptep) && !is_large_pte(*sptep) &&
- spte_to_child_sp(*sptep) && spte_to_child_sp(*sptep)->gfn == gfn)
+ if (is_shadow_present_pte(*sptep) &&
+ !is_large_pte(*sptep) &&
+ spte_to_child_sp(*sptep) &&
+ spte_to_child_sp(*sptep)->gfn == gfn &&
+ spte_to_child_sp(*sptep)->role.word == role.word)
return ERR_PTR(-EEXIST);
role = kvm_mmu_child_role(sptep, direct, access);
================================================================================
* CONTEXT DIFFERENCES - surrounding code differences between the patches *
================================================================================
--- b/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -2217,7 +2217,7 @@
union kvm_mmu_page_role role;
if (is_shadow_present_pte(*sptep) && !is_large_pte(*sptep) &&
- to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK) && to_shadow_page(*sptep & SPTE_BASE_ADDR_MASK)->gfn == gfn)
+ spte_to_child_sp(*sptep) && spte_to_child_sp(*sptep)->gfn == gfn)
return ERR_PTR(-EEXIST);
role = kvm_mmu_child_role(sptep, direct, access);This is an automated interdiff check for backported commits. |
JIRA PR Check Results95 commit(s) with issues found: Commit
|
|
❌ Validation checks completed with issues View full results: https://github.com/ctrliq/kernel-src-tree/actions/runs/28822279125 |
Summary
This PR has been automatically created after successful completion of all CI stages.
Commit Message(s)
Reproducing and testing Januscape
Prerequisites
Steps (inside the guest)
makesudo rmmod kvm_intelsudo insmod poc.kosudo rmmod pocsudo insmod poc.koExpected result
The host panics with a KVM shadow-MMU rmap corruption, with a signature like:
Verifying the fix
Install the patched kernel on the host, boot into it, and repeat the same PoC runs from the guest. With the fix applied the host survives all runs (no pte_list_remove)
Test Results
✅ Build Stage
✅ Boot Verification
✅ Kernel Selftests
✅ LTP Results
aarch64 regressions:
🤖 This PR was automatically generated by GitHub Actions
Run ID: 28801071493