In the Linux kernel, the following vulnerability has been resolved:
LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY
kvm_arch_prepare_memory_region() computes new->arch.flags, i.e. whether
a memslot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE,
only for KVM_MR_CREATE and KVM_MR_MOVE, and returns early for every
other change. But the generic code allocates a zeroed memslot for every
change and never copies old->arch, so after a KVM_MR_FLAGS_ONLY update,
e.g. toggling KVM_MEM_LOG_DIRTY_PAGES for live migration, the active
memslot has arch.flags == 0.
With both flags clear, fault_supports_huge_mapping() falls through to
the alignment check on the HVA range alone, which no longer verifies
that the GPA and HVA have the same offset within a PMD. A memslot that
was marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset
mismatch can then be mapped with PMD entries on read faults, and since
kvm_map_page() aligns the gfn and the pfn independently, the guest ends
up accessing the wrong host pages, exactly the "d -> f, e -> g" case
described in the comment above the check.
Carry the arch flags over from the old memslot for KVM_MR_FLAGS_ONLY,
as the GPA, HVA and size are guaranteed to be unchanged for that case.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS Score: 8.8
AV:L - The bug is reached from a LoongArch KVM guest page fault on the host KVM_RUN path (kvm_arch_vcpu_ioctl_run -> kvm_handle_exit -> kvm_handle_fault -> kvm_handle_mm_fault -> kvm_map_page) after KVM_SET_USER_MEMORY_REGION FLAGS_ONLY; there is no network or physical path.
AC:L - After FLAGS_ONLY zeros memslot arch.flags, a guest load to an interior GPA of a GPA/HVA-offset-mismatched slot with host THP backing deterministically installs a PMD because kvm_map_page aligns gfn and pfn independently; the VMM chooses the memslot and dirty-log toggle, and THP is a common default, not a rare config or uncontrolled race.
PR:L - A tenant guest or a host kvm-group user running QEMU is sufficient: /dev/kvm and kvm_vm_ioctl() have no capable() check, and the fault path has none either. Init-namespace root is not required, so this is Low rather than High.
UI:N - The attacker guest issues the faulting load or store itself during KVM_RUN; no separate victim action such as mounting a filesystem, opening a crafted file, or confirming a prompt is required.
S:C - kvm_map_page installs stage-2 PMD entries that bind guest GPAs to the wrong host PFNs, breaking the hypervisor GPA-to-HVA contract and crossing the KVM guest-to-host isolation boundary, which CNA guidance rates Changed for KVM guest-to-host escape.
C:H - On read faults, fault_supports_huge_mapping() allows a PMD that maps the guest onto the wrong host pages (the commit's d->f, e->g case), giving the guest an unauthorized read of the host physical pages backing that 2MB block.
I:H - After dirty logging is toggled off (another FLAGS_ONLY that also leaves arch.flags at 0), write faults install writable huge mappings to those same wrong host PFNs, so the guest can modify host pages the memslot did not bind to that GPA.
A:H - Aliased stage-2 PMDs scramble guest RAM and, during live migration, produce a corrupted destination image that can crash the VM; incorrect huge PFNs can also oops the host if the aligned range is not valid RAM, denying service to the hypervisor and co-located VMs.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The bug is reached from a LoongArch KVM guest page fault on the host KVM_RUN path (kvm_arch_vcpu_ioctl_run -> kvm_handle_exit -> kvm_handle_fault -> kvm_handle_mm_fault -> kvm_map_page) after KVM_SET_USER_MEMORY_REGION FLAGS_ONLY; there is no network or physical path.
AC:L - After FLAGS_ONLY zeros memslot arch.flags, a guest load to an interior GPA of a GPA/HVA-offset-mismatched slot with host THP backing deterministically installs a PMD because kvm_map_page aligns gfn and pfn independently; the VMM chooses the memslot and dirty-log toggle, and THP is a common default, not a rare config or uncontrolled race.
PR:L - A tenant guest or a host kvm-group user running QEMU is sufficient: /dev/kvm and kvm_vm_ioctl() have no capable() check, and the fault path has none either. Init-namespace root is not required, so this is Low rather than High.
UI:N - The attacker guest issues the faulting load or store itself during KVM_RUN; no separate victim action such as mounting a filesystem, opening a crafted file, or confirming a prompt is required.
S:C - kvm_map_page installs stage-2 PMD entries that bind guest GPAs to the wrong host PFNs, breaking the hypervisor GPA-to-HVA contract and crossing the KVM guest-to-host isolation boundary, which CNA guidance rates Changed for KVM guest-to-host escape.
C:H - On read faults, fault_supports_huge_mapping() allows a PMD that maps the guest onto the wrong host pages (the commit's d->f, e->g case), giving the guest an unauthorized read of the host physical pages backing that 2MB block.
I:H - After dirty logging is toggled off (another FLAGS_ONLY that also leaves arch.flags at 0), write faults install writable huge mappings to those same wrong host PFNs, so the guest can modify host pages the memslot did not bind to that GPA.
A:H - Aliased stage-2 PMDs scramble guest RAM and, during live migration, produce a corrupted destination image that can crash the VM; incorrect huge PFNs can also oops the host if the aligned range is not valid RAM, denying service to the hypervisor and co-located VMs.
CVSS 3.1