In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR
KVM currently maps the L1 VNCR into the host stage-1 by relying entirely
on the permissions of the guest stage-1. At the same time, it is
entirely possible that the backing PFN is read-only (e.g. RO memslot),
meaning that the L1 VNCR should use at most a read-only mapping.
Cache the writability of the PFN in the VNCR TLB and use it to constrain
the resulting fixmap permissions. Promote VNCR permission faults to an
SEA in the case where the guest attempts to write to a read-only
endpoint. Conveniently, this also plugs a page leak found by Sashiko [*]
resulting from the early return for a read-only PFN.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H
CVSS Score: 9
AV:L - The flaw is reached only when a nested arm64 KVM guest hypervisor triggers VNCR_EL2 data aborts handled via KVM_RUN through kvm_handle_vncr_abort() and kvm_translate_vncr(); no network, adjacent-radio, or physical-device path reaches this code.
AC:L - An attacker controlling an L1 nested-hypervisor VM can reliably configure VNCR_EL2, guest stage-1 page tables, and KVM_MEM_READONLY memslots, then trigger translation faults and writes; nested virt on arm64 cloud hosts is an attacker-selectable deployment, not an uncontrollable condition.
PR:N - Exploitation requires no host root or init-namespace capabilities beyond running code in a tenant KVM guest on an arm64 host with nested virtualization enabled; the attacker operates entirely from within their assigned VM, consistent with other arm64 KVM guest CVE scoring.
UI:N - No victim user or administrator action is required beyond the attacker operating their own nested-virtualization workload; VNCR faults, fixmap remapping, and repeated write triggers are fully attacker-driven from within the guest.
S:C - The bug defeats host KVM enforcement of read-only memslots via host fixmap mappings and leaks host kernel page references on the error path, crossing the guest-to-hypervisor security boundary by affecting host memory accounting and VMM-imposed memory protections beyond the guest authority.
C:N - The vulnerability provides a write and page-reference leak primitive, not an out-of-bounds read, use-after-free, or other information-disclosure path; corrupted RO guest pages are attacker-influenced backing store, not arbitrary host kernel memory reads.
I:H - Mapping an RO-backed PFN into the host fixmap with PAGE_KERNEL lets a guest hypervisor write to memory the VMM marked KVM_MEM_READONLY, bypassing a host-enforced integrity control and enabling modification of protected guest or hypervisor pages such as firmware, virtio metadata, or EL2 state.
A:H - Repeated write faults to read-only VNCR endpoints leak a faulted-in page reference on each early -EFAULT return without kvm_release_faultin_page(), enabling sustained host kernel memory exhaustion and denial of service to co-resident workloads on the hypervisor.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
None |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The flaw is reached only when a nested arm64 KVM guest hypervisor triggers VNCR_EL2 data aborts handled via KVM_RUN through kvm_handle_vncr_abort() and kvm_translate_vncr(); no network, adjacent-radio, or physical-device path reaches this code.
AC:L - An attacker controlling an L1 nested-hypervisor VM can reliably configure VNCR_EL2, guest stage-1 page tables, and KVM_MEM_READONLY memslots, then trigger translation faults and writes; nested virt on arm64 cloud hosts is an attacker-selectable deployment, not an uncontrollable condition.
PR:N - Exploitation requires no host root or init-namespace capabilities beyond running code in a tenant KVM guest on an arm64 host with nested virtualization enabled; the attacker operates entirely from within their assigned VM, consistent with other arm64 KVM guest CVE scoring.
UI:N - No victim user or administrator action is required beyond the attacker operating their own nested-virtualization workload; VNCR faults, fixmap remapping, and repeated write triggers are fully attacker-driven from within the guest.
S:C - The bug defeats host KVM enforcement of read-only memslots via host fixmap mappings and leaks host kernel page references on the error path, crossing the guest-to-hypervisor security boundary by affecting host memory accounting and VMM-imposed memory protections beyond the guest authority.
C:N - The vulnerability provides a write and page-reference leak primitive, not an out-of-bounds read, use-after-free, or other information-disclosure path; corrupted RO guest pages are attacker-influenced backing store, not arbitrary host kernel memory reads.
I:H - Mapping an RO-backed PFN into the host fixmap with PAGE_KERNEL lets a guest hypervisor write to memory the VMM marked KVM_MEM_READONLY, bypassing a host-enforced integrity control and enabling modification of protected guest or hypervisor pages such as firmware, virtio metadata, or EL2 state.
A:H - Repeated write faults to read-only VNCR endpoints leak a faulted-in page reference on each early -EFAULT return without kvm_release_faultin_page(), enabling sustained host kernel memory exhaustion and denial of service to co-resident workloads on the hypervisor.
CVSS 3.1