In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: nv: Re-translate VNCR before injecting abort
KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts
for a write, similar to how a regular stage-2 mapping is handled. It is
entirely possible that the guest reads from the VNCR before writing to
it, in which case the PFN could only be read-only.
Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR
abort, allowing the host mapping to be faulted in for write the second
time around. Interestingly enough, this also satisfies the ordering
requirements of FEAT_ETS2/3 between descriptor updates and MMU faults.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CVSS Score: 9.3
AV:L - The flaw is reached only when an arm64 nested-KVM L1 hypervisor triggers VNCR_EL2 data aborts (ESR_ELx_EC_DABT_CUR with ESR_ELx_VNCR) handled via KVM_RUN through kvm_handle_vncr_abort(); no network, adjacent-radio, or physical-device path reaches this code.
AC:L - An attacker controlling an L1 nested-hypervisor VM can reliably issue read-then-write VNCR accesses, remap the VNCR page, and force translation/permission faults; 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 hypervisor 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 nested-virt CVE scoring.
UI:N - No victim user or administrator action is required beyond the attacker operating their own nested-virtualization workload; VNCR faults, pseudo-TLB reuse, and repeated write triggers are fully attacker-driven from within the guest.
S:C - Stale VNCR pseudo-TLB and fixmap state lets guest-controlled faults cause host KVM to map and access the wrong guest physical pages when emulating EL2 register state, crossing the guest-to-hypervisor security boundary beyond the guest's intended authority.
C:H - Reusing a cached VNCR translation without re-walking guest page tables can make the host read unintended guest physical pages through the per-CPU fixmap during VNCR emulation, providing a stale-translation information-disclosure primitive across guest memory views.
I:H - Without re-translation on write aborts, a writable host fixmap established under a stale read-only fault can let the hypervisor write nested EL2 register values into the wrong guest physical page, corrupting memory the VMM expected to isolate.
A:H - Incorrect permission/external-abort injection on VNCR write faults after a prior read leaves nested hypervisors unable to progress and can drive tight host-side fault-handling loops, causing CPU exhaustion and denial of service to co-resident workloads.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The flaw is reached only when an arm64 nested-KVM L1 hypervisor triggers VNCR_EL2 data aborts (ESR_ELx_EC_DABT_CUR with ESR_ELx_VNCR) handled via KVM_RUN through kvm_handle_vncr_abort(); no network, adjacent-radio, or physical-device path reaches this code.
AC:L - An attacker controlling an L1 nested-hypervisor VM can reliably issue read-then-write VNCR accesses, remap the VNCR page, and force translation/permission faults; 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 hypervisor 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 nested-virt CVE scoring.
UI:N - No victim user or administrator action is required beyond the attacker operating their own nested-virtualization workload; VNCR faults, pseudo-TLB reuse, and repeated write triggers are fully attacker-driven from within the guest.
S:C - Stale VNCR pseudo-TLB and fixmap state lets guest-controlled faults cause host KVM to map and access the wrong guest physical pages when emulating EL2 register state, crossing the guest-to-hypervisor security boundary beyond the guest's intended authority.
C:H - Reusing a cached VNCR translation without re-walking guest page tables can make the host read unintended guest physical pages through the per-CPU fixmap during VNCR emulation, providing a stale-translation information-disclosure primitive across guest memory views.
I:H - Without re-translation on write aborts, a writable host fixmap established under a stale read-only fault can let the hypervisor write nested EL2 register values into the wrong guest physical page, corrupting memory the VMM expected to isolate.
A:H - Incorrect permission/external-abort injection on VNCR write faults after a prior read leaves nested hypervisors unable to progress and can drive tight host-side fault-handling loops, causing CPU exhaustion and denial of service to co-resident workloads.
CVSS 3.1