[ciqlts8_6] Multiple patches tested (2 commits) by ciq-kernel-automation[bot] · Pull Request #1407 · ctrliq/kernel-src-tree

ciq-kernel-automation · 2026-07-06T18:59:58Z

Summary

This PR has been automatically created after successful completion of all CI stages.

Commit Message(s)

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 -
commit-source-sha 0cb2af2ea66ad95873455d8a1d0f6f4e13fef645
commit-source https://lore.kernel.org/all/20260626112634.1778506-1-pbonzini@redhat.com/
upstream-diff |
	This is a HAND-PORT, not a cherry-pick.  Upstream commit
	0cb2af2ea66ad fixes kvm_mmu_get_child_sp() by adding a
	spte_to_child_sp(*sptep)->gfn == gfn check to its -EEXIST reuse
	guard.  That function (and spte_to_child_sp/kvm_mmu_child_role,
	the whole get_child_sp/get_shadow_page split) does NOT exist on
	this 4.18-based tree, which predates the ~6.2 KVM MMU refactor and
	still uses kvm_mmu_get_page() + link_shadow_page().

KVM: x86: Fix shadow paging use-after-free due to unexpected role

jira VULN-191426
cve CVE-2026-53359
commit-author Paolo Bonzini <pbonzini@redhat.com>
commit -
commit-source-sha 81ccda30b4e83d8f5cc4fd50503c44e3a33abfeb
commit-source https://lore.kernel.org/all/20260626112634.1778506-1-pbonzini@redhat.com/
upstream-diff |
	This is a HAND-PORT, not a cherry-pick.  Upstream commit
	81ccda30b4e8 fixes kvm_mmu_get_child_sp() by adding
	spte_to_child_sp(*sptep)->role.word == role.word to its -EEXIST
	reuse guard, on top of the unexpected-GFN check.  That function does
	not exist on this 4.18-based tree (see the prerequisite "unexpected
	GFN" commit for the full rationale); the equivalent guard lives in
	the shared helper kvm_mmu_child_sp_matches() applied at the three
	fault-path reuse sites.  This commit adds the role.word comparison
	to that helper, using kvm_mmu_child_role() to derive the expected
	role exactly as kvm_mmu_get_page() does.  Functionally equivalent to
	upstream.

Reproducing and testing Januscape

Prerequisites

A bare-metal host running LTS 8.6 without the two fixes (GFN + role).
A guest VM (also LTS 8.6, or any kernel, the guest kernel is not what matters).
Nested virtualization enabled on the host (kvm_intel nested=1), and the guest CPU set to host-passthrough so it can run the PoC's nested VMX/EPT workload.

Steps (inside the guest)

Copy poc.c and Makefile into the guest.
Build the module:
make
Load it (unload the guest's kvm_intel first for a clean slate):
sudo rmmod kvm_intel
sudo insmod poc.ko
The PoC pins CPU and races the host's page-fault handler. A single insmod does not always win the race - it may crash on the first run, or take several.
If it doesn't crash, unload and retry:
sudo rmmod poc
sudo insmod poc.ko
Repeat. On an unpatched host you should see a crash within ~10 runs (a fresh insmod re-primes the race window each time).

Expected result

The host panics with a KVM shadow-MMU rmap corruption, with a signature like:

gfn mismatch under direct page <A> (expected <B>, got <C>)
pte_list_remove: <ptr> 0->BUG          # el9 / 5.14: pte_list_remove, mmu.c:940
kernel BUG at arch/x86/kvm/mmu/mmu.c:940!
RIP: pte_list_remove+... [kvm]
Call Trace: kvm_mmu_page_fault → mmu_set_spte → ... [kvm]
Comm: CPU N/KVM

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

Architecture	Build Time	Total Time
x86_64	22m 49s	23m 44s
aarch64	9m 22s	10m 1s

View build logs

✅ Boot Verification

Status: Passed (all architectures)
View boot logs

✅ Kernel Selftests

Architecture	Passed	Failed	Compared Against	Status
x86_64	108	31	ciqlts8_6	✅ No regressions
aarch64	67	20	ciqlts8_6	✅ No regressions

View kselftest logs

✅ LTP Results

Architecture	Passed	Failed	Compared Against	Status
x86_64	1443	14	ciqlts8_6	❌ 1 regressions
aarch64	1425	14	ciqlts8_6	✅ No regressions

View LTP logs

x86_64 regressions:

futex_wake02 (PASS -> FAIL)
x86_64 newly passing:
fs_perms03 (PASS)
fs_perms04 (PASS)
fs_perms05 (PASS)
fs_perms06 (PASS)

🤖 This PR was automatically generated by GitHub Actions
Run ID: 28801347436

jira VULN-186742 cve CVE-2026-46113 commit-author Sean Christopherson <seanjc@google.com> commit - commit-source-sha 0cb2af2ea66ad95873455d8a1d0f6f4e13fef645 commit-source https://lore.kernel.org/all/20260626112634.1778506-1-pbonzini@redhat.com/ upstream-diff | This is a HAND-PORT, not a cherry-pick. Upstream commit 0cb2af2 fixes kvm_mmu_get_child_sp() by adding a spte_to_child_sp(*sptep)->gfn == gfn check to its -EEXIST reuse guard. That function (and spte_to_child_sp/kvm_mmu_child_role, the whole get_child_sp/get_shadow_page split) does NOT exist on this 4.18-based tree, which predates the ~6.2 KVM MMU refactor and still uses kvm_mmu_get_page() + link_shadow_page(). On this tree the interior-SPTE reuse happens in the fault-path walkers __direct_map() and FNAME(fetch): after drop_large_spte(), a present non-large SPTE is reused as-is (skipping the kvm_mmu_get_page() alloc path that would validate gfn), with no re-check that the referenced child shadow page still maps the expected gfn. The equivalent guard is therefore applied at each of the three reuse sites via a shared helper kvm_mmu_child_sp_matches(); on mismatch the stale child SPTE is zapped (mmu_page_zap_pte + remote flush) so the correct child is (re)allocated. kvm_mmu_child_role() factors out kvm_mmu_get_page()'s role derivation so the guard and the allocator cannot drift. Functionally equivalent to upstream. Commit 0cb2af2 ("KVM: x86: Fix shadow paging use-after-free due to unexpected GFN") fixes a shadow paging mismatch between the stored and computed GFNs. The bug can be triggered by changing a PDE mapping from outside the guest and then deleting a memslot: rmap_remove() misses entries whose leaf SPTE gfn does not match the gfn of the struct kvm_mmu_page. The freed shadow page's rmap entry survives, and later walks of that gfn (dirty logging, MMU notifier invalidation, ...) dereference an sptep 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: Shreeya Patel <spatel@ciq.com>

jira VULN-191426 cve CVE-2026-53359 commit-author Paolo Bonzini <pbonzini@redhat.com> commit - commit-source-sha 81ccda3 commit-source https://lore.kernel.org/all/20260626112634.1778506-1-pbonzini@redhat.com/ upstream-diff | This is a HAND-PORT, not a cherry-pick. Upstream commit 81ccda3 fixes kvm_mmu_get_child_sp() by adding spte_to_child_sp(*sptep)->role.word == role.word to its -EEXIST reuse guard, on top of the unexpected-GFN check. That function does not exist on this 4.18-based tree (see the prerequisite "unexpected GFN" commit for the full rationale); the equivalent guard lives in the shared helper kvm_mmu_child_sp_matches() applied at the three fault-path reuse sites. This commit adds the role.word comparison to that helper, using kvm_mmu_child_role() to derive the expected role exactly as kvm_mmu_get_page() does. Functionally equivalent 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. A similar hole remains if the modified PDE points to a non-leaf page: the gfn can be made to match, but the role does not. The original large 2MB page creates a kvm_mmu_page with direct=1, while the new 4KB mapping needs one with direct=0; because the reuse path did not compare the role, the direct=1 page was reused. Installing a leaf SPTE then records an rmap entry under the walk's gfn, but when that child is zapped its parent has direct=1 and kvm_mmu_page_get_gfn() computes the gfn as sp->gfn + index instead of using sp->gfns[], so the recorded entry is not removed. When the memslot is dropped the shadow page is freed but the rmap entry survives, and later walks dereference an sptep 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: Shreeya Patel <spatel@ciq.com>

github-actions · 2026-07-06T19:10:03Z

🤖 Validation Checks In Progress Workflow run: https://github.com/ctrliq/kernel-src-tree/actions/runs/28816580920

github-actions · 2026-07-06T19:11:02Z

JIRA PR Check Results

2 commit(s) with issues found:

Commit `649ff5c53d32`

Summary: KVM: x86: Fix shadow paging use-after-free due to unexpected role

❌ Errors:

VULN-191426: Status is 'To Do', expected 'In Progress'

⚠️ Warnings:

VULN-191426: No time logged - please log time manually

Commit `51e2c7573264`

Summary: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN

❌ Errors:

VULN-186742: Status is 'To Do', expected 'In Progress'

⚠️ Warnings:

VULN-186742: No time logged - please log time manually

Summary: Checked 2 commit(s) total.

github-actions · 2026-07-06T19:11:03Z

❌ Validation checks completed with issues View full results: https://github.com/ctrliq/kernel-src-tree/actions/runs/28816580920

bmastbergen

🥌

kerneltoast · 2026-07-06T21:47:07Z

Commit-source-sha is mangled on 51e2c75

The first 13 chars of it are correct o_O

kerneltoast

I'm reworking this backport. drop_large_spte() was kept even though it's redundant now and the changes to the checks in FNAME(fetch) are missing !is_large_pte(*it.sptep). Several of the parameters passed to kvm_mmu_child_sp_matches() are never used too.

shreeya-patel98 added 2 commits July 6, 2026 07:27

ciq-kernel-automation Bot added the created-by-kernelci Tag PRs that were automatically created when a user branch was pushed to the repo (kernelCI) label Jul 6, 2026

PlaidCat requested a review from a team July 6, 2026 20:42

bmastbergen approved these changes Jul 6, 2026

View reviewed changes

bmastbergen requested a review from a team July 6, 2026 21:24

kerneltoast requested changes Jul 7, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[ciqlts8_6] Multiple patches tested (2 commits)#1407

[ciqlts8_6] Multiple patches tested (2 commits)#1407
ciq-kernel-automation[bot] wants to merge 2 commits into
ciqlts8_6from
{shreeya_januscape}_ciqlts8_6

ciq-kernel-automation Bot commented Jul 6, 2026 •

edited by shreeya-patel98

Loading

Uh oh!

github-actions Bot commented Jul 6, 2026

Uh oh!

github-actions Bot commented Jul 6, 2026

Uh oh!

github-actions Bot commented Jul 6, 2026

Uh oh!

bmastbergen left a comment

Uh oh!

kerneltoast commented Jul 6, 2026

Uh oh!

kerneltoast left a comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

ciq-kernel-automation Bot commented Jul 6, 2026 • edited by shreeya-patel98 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Commit Message(s)

Reproducing and testing Januscape

Test Results

✅ Build Stage

✅ Boot Verification

✅ Kernel Selftests

✅ LTP Results

Uh oh!

github-actions Bot commented Jul 6, 2026

Uh oh!

github-actions Bot commented Jul 6, 2026

JIRA PR Check Results

Commit 649ff5c53d32

Commit 51e2c7573264

Uh oh!

github-actions Bot commented Jul 6, 2026

Uh oh!

bmastbergen left a comment

Choose a reason for hiding this comment

Uh oh!

kerneltoast commented Jul 6, 2026

Uh oh!

kerneltoast left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

ciq-kernel-automation Bot commented Jul 6, 2026 •

edited by shreeya-patel98

Loading

Commit `649ff5c53d32`

Commit `51e2c7573264`