[LTS 9.2] CVE-2026-23401

[pvts-mat]

[LTS 9.2]

CVE-2026-23401

VULN-180395

Commits

CVE-2026-23401

KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE

jira VULN-180395
cve CVE-2026-23401
commit-author Sean Christopherson <seanjc@google.com>
commit aad885e774966e97b675dfe928da164214a71605
upstream-diff Used linux-6.1.y backport
  ed5909992f344a7d3f4024261e9f751d9618a27d for the clean pick. Strictly
  speaking, the upstream's `kvm_flush_remote_tlbs_gfn(vcpu->kvm, gfn,
  level)' call corresponds to LTS 9.2-native
  `kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn &
  -KVM_PAGES_PER_HPAGE(level), KVM_PAGES_PER_HPAGE(level))'. See the
  non-backported commits:
  - 9ffe9265375cbaf6c01647e31ae9fee8595b698c ("KVM: x86/mmu: Fix wrong gfn
    range of tlb flushing in kvm_set_pte_rmapp()"),
  - 8c63e8c2176552d5c003d7459609383d32bf47f3 ("KVM: x86/mmu: Rename
    kvm_flush_remote_tlbs_with_address()"),
  - c667a3baeddcc982bf512c126aec8d0f04adecfe ("KVM: x86/mmu: Move
    round_gfn_for_level() helper into mmu_internal.h").
  Nevertheless preserved linux-6.1.y's
  `kvm_flush_remote_tlbs_with_address()' call without `gfn' rounding, as
  that's exactly how it's used in the same function a few lines later,
  strongly suggesting that the issues raised in commit 9ffe92653 don't
  apply here.

The KVM module uses different table flushing procedures across time and code space, those relevant to the CVE-2026-23401 fix being:

• kvm_flush_remote_tlbs_with_range,
• kvm_flush_remote_tlbs_with_address,
• kvm_flush_remote_tlbs_range,
• kvm_flush_remote_tlbs_gfn.

Their evolution can best be presented in the following table, with commits starting from the oldest, up to what can be found in the upstream at the moment of the aad885e fix:

`kernel-mainline`	`ciqlts8_6`	`ciqlts9_2`	`linux-6.1.y`	`linux-5.15.y`	`kvm_flush_remote_tlbs_with_range`	`kvm_flush_remote_tlbs_with_address`	`kvm_flush_remote_tlbs_range`	`kvm_flush_remote_tlbs_gfn`
40ef75a	c4b11c6	40ef75a	40ef75a	40ef75a	Defined in `arch/x86/kvm/mmu.c`	Defined in `arch/x86/kvm/mmu.c` (calls `kvm_flush_remote_tlbs_with_range`)	-	-
c50d8ae	94adbae	c50d8ae	c50d8ae	c50d8ae	Moved to `arch/x86/kvm/mmu/mmu.c`	Moved to `arch/x86/kvm/mmu/mmu.c`	-	-
2f2fad0	b10939c	2f2fad0	2f2fad0	2f2fad0	0	Made public (non-static)	-	-
9ffe926	-	-	-	-	0	0	-	Definition
28e4b45	-	-	-	-	Inlined into `kvm_flush_remote_tlbs_with_address`	Inlined the `kvm_flush_remote_tlbs_with_range` call	-	0
8c63e8c	-	-	-	-	-	Renamed to `kvm_flush_remote_tlbs_range`	Created from `kvm_flush_remote_tlbs_with_address`	Change inner call from `kvm_flush_remote_tlbs_with_address` to `kvm_flush_remote_tlbs_range`
9d4655d	-	-	-	-	-	-	Changed arg `u64 pages` → `gfn_t nr_pages`	0
d478899	-	-	-	-	-	-	Moved to `virt/kvm/kvm_main.c` and changed body	0

Upstream fix uses:

kernel-src-tree/arch/x86/kvm/mmu/mmu.c

Line 3074 in aad885e

kvm_flush_remote_tlbs_gfn(vcpu->kvm, gfn, level);

The kvm_flush_remote_tlbs_gfn() function is defined as:

kernel-src-tree/arch/x86/kvm/mmu/mmu_internal.h

Lines 211 to 216 in aad885e

	/* Flush the given page (huge or not) of guest memory. */
	static inline void kvm_flush_remote_tlbs_gfn(struct kvm *kvm, gfn_t gfn, int level)
	{
	kvm_flush_remote_tlbs_range(kvm, gfn_round_for_level(gfn, level),
	KVM_PAGES_PER_HPAGE(level));
	}

The kvm_flush_remote_tlbs_range() call corresponds to kvm_flush_remote_tlbs_with_address() call - the function was renamed in 8c63e8c. The gfn_round_for_level() function is

kernel-src-tree/arch/x86/kvm/mmu/mmu_internal.h

Lines 197 to 200 in aad885e

	static inline gfn_t gfn_round_for_level(gfn_t gfn, int level)
	{
	return gfn & -KVM_PAGES_PER_HPAGE(level);
	}

It also exists in LTS 9.2, under a similar name round_gfn_for_level() (moved and renamed in c667a3b).

kernel-src-tree/arch/x86/kvm/mmu/tdp_iter.c

Lines 18 to 21 in cf9f720

	static gfn_t round_gfn_for_level(gfn_t gfn, int level)
	{
	return gfn & -KVM_PAGES_PER_HPAGE(level);
	}

(It's private, however, so using it in arch/x86/kvm/mmu/mmu.c would require publicizing it (basically what c667a3b does)).

Taking all of the above into account would result in a LTS 9.2-corresponding call:

kvm_flush_remote_tlbs_with_address(vcpu->kvm,
				   gfn & -KVM_PAGES_PER_HPAGE(level),
				   KVM_PAGES_PER_HPAGE(level));

The gfn & -KVM_PAGES_PER_HPAGE(level) part is a rounding of gfn to a value appropriate for kvm_flush_remote_tlbs_with_address() call. Failure to do so in the kvm_set_pte_rmap() function motivated the introduction of kvm_flush_remote_tlbs_gfn() in 9ffe926:

Also introduce a helper function to flush the given
page (huge or not) of guest memory, which would help prevent future
buggy use of kvm_flush_remote_tlbs_with_address() in such case.

The transition from using kvm_flush_remote_tlbs_with_address() to kvm_flush_remote_tlbs_gfn() was done in a few commits: 9ffe926, 1e20384, 1b2dc73, 4ad980a.

However, the CVE-2026-23401-fix-modified function mmu_set_spte() uses kvm_flush_remote_tlbs_with_address() call without gfn rounding just a few lines later

kernel-src-tree/arch/x86/kvm/mmu/mmu.c

Lines 2838 to 2839 in cf9f720

	kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn,
	KVM_PAGES_PER_HPAGE(level));

and the transition of this call to kvm_flush_remote_tlbs_gfn() on upstream was done in a non-bugfixing commit 4ad980a. This strongly suggests that gfn is already rounded to the proper value.

Retained the linux-6.1.y solution (aligning also with rocky8_10 fix in 9b906d0) for the sake of simplicity.

kABI check: passed

[0/1] kabi_check_kernel	Check ABI of kernel [ciqlts9_2-CVE-2026-23401]	_kabi_check_kernel__x86_64--test--ciqlts9_2-CVE-2026-23401
+ dist_git_version=el-9.2
+ local_version=ciqlts9_2-CVE-2026-23401
+ arch=x86_64
+ user=pvts
+ buildmachine=x86_64--build--ciqlts9_2
+ virsh_timeout=600
+ ssh_daemon_wait=20
+ src_dir=/mnt/code/kernel-dist-git-el-9.2
+ build_dir=/mnt/build_files/kernel-src-tree-ciqlts9_2-CVE-2026-23401
+ sudo chmod +x /data/src/ctrliq-github-haskell/kernel-dist-git-el-9.2/SOURCES/check-kabi
+ ninja-back/virssh.xsh --max 8 --shutdown-on-success --shutdown-on-failure --timeout 600 --ssh-daemon-wait 20 pvts x86_64--build--ciqlts9_2 ''\''/mnt/code/kernel-dist-git-el-9.2/SOURCES/check-kabi'\'' -k '\''/mnt/code/kernel-dist-git-el-9.2/SOURCES/Module.kabi_x86_64'\'' -s '\''/mnt/build_files/kernel-src-tree-ciqlts9_2-CVE-2026-23401/Module.symvers'\'''
kABI check passed
+ touch state/kernels/ciqlts9_2-CVE-2026-23401/x86_64/kabi_checked

Boot test: passed

boot-test.log

Kselftests: passed relative

Reference

kselftests–ciqlts9_2–run1.log

Patch

kselftests–ciqlts9_2-CVE-2026-23401–run1.log

Comparison

The tests results for the reference and the patch are the same.

$ ktests.xsh diff -d kselftests*.log

Column    File
--------  ----------------------------------------------
Status0   kselftests--ciqlts9_2--run1.log
Status1   kselftests--ciqlts9_2-CVE-2026-23401--run1.log

full-tests-results-comparison.log

[PlaidCat]

[bmastbergen]

🥌