In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Remove VM-wide VNCR mapping counter
The global VNCR mapping counter is used to decide whether an L1
provided VNCR page is mapped in L0 on any CPU at the point of
dealing with a TLB invalidation. It is incremented when a mapping
is made in the fixmap, and decremented when unmapped.
As it turns out, this tracking has several flaws:
-
we are trying to invalidate TLBs, and the mapping is only an
opportunistic consequence of the TLB. Checking this counter to
decide whether a TLB needs to be invalidated may result in missed
invalidations.
-
an L1 vcpu invalidating its own TLB (a very likely case) will not
succeed in invalidating the VNCR pseudo TLB because that page is
not mapped in L0 at this stage.
Given that this tracking fails at delivering the minimum guarantees
that are required and is only a performance optimisation, remove it
completely.
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 - An arm64 nested L1 hypervisor reaches the bug by executing trapped EL1/EL2 TLBI during KVM_RUN; kvm_hyp_handle_tlbi_el2 then skips kvm_handle_s1e2_tlbi. This is local KVM ioctl/guest execution, not a network, adjacent-radio, or physical-device path.
AC:L - After vcpu_put unmaps the VNCR fixmap, vncr_map_count is zero while vt->valid still caches the HPA, so an L1 TLBI takes the hyp fast path and never invalidates the pseudo-TLB. The attacker controls mapping, unmap, and invalidation; this is the usual L1-after-L2 sequence, not an uncontrollable race.
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 population, vcpu_put unmap, guest TLBI, and L2 re-entry are fully attacker-driven.
S:C - Missed VNCR invalidation leaves a writable host per-CPU fixmap covering a stale HPA after L1 S1 teardown, so host KVM keeps reading and writing that page while emulating EL2 register state, crossing the guest-to-hypervisor security boundary.
C:H - The stale VNCR pseudo-TLB retains the old HPA and kvm_map_l1_vncr remaps it PAGE_KERNEL; host NV2/sysreg emulation then reads leftover EL2 register state from a recycled IPA or L2-visible page, a translation-cache use-after-invalidate disclosure primitive.
I:H - Hardware NV2 and kvm_map_l1_vncr keep a writable kernel mapping of the stale HPA, so nested EL2 register writes land in a page L1 already remapped or reused for L2, giving a use-after-invalidate write primitive against nested hypervisor state and host-mediated guest memory.
A:H - A stale writable VNCR mapping can oops or panic the host via inconsistent nested MMU or sysreg state, and corrupting L1 EL2 control state or reused pages can hang or crash the hypervisor and co-resident nested guests; the attacker can retrigger the missed-invalidation sequence.
| 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 - An arm64 nested L1 hypervisor reaches the bug by executing trapped EL1/EL2 TLBI during KVM_RUN; kvm_hyp_handle_tlbi_el2 then skips kvm_handle_s1e2_tlbi. This is local KVM ioctl/guest execution, not a network, adjacent-radio, or physical-device path.
AC:L - After vcpu_put unmaps the VNCR fixmap, vncr_map_count is zero while vt->valid still caches the HPA, so an L1 TLBI takes the hyp fast path and never invalidates the pseudo-TLB. The attacker controls mapping, unmap, and invalidation; this is the usual L1-after-L2 sequence, not an uncontrollable race.
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 population, vcpu_put unmap, guest TLBI, and L2 re-entry are fully attacker-driven.
S:C - Missed VNCR invalidation leaves a writable host per-CPU fixmap covering a stale HPA after L1 S1 teardown, so host KVM keeps reading and writing that page while emulating EL2 register state, crossing the guest-to-hypervisor security boundary.
C:H - The stale VNCR pseudo-TLB retains the old HPA and kvm_map_l1_vncr remaps it PAGE_KERNEL; host NV2/sysreg emulation then reads leftover EL2 register state from a recycled IPA or L2-visible page, a translation-cache use-after-invalidate disclosure primitive.
I:H - Hardware NV2 and kvm_map_l1_vncr keep a writable kernel mapping of the stale HPA, so nested EL2 register writes land in a page L1 already remapped or reused for L2, giving a use-after-invalidate write primitive against nested hypervisor state and host-mediated guest memory.
A:H - A stale writable VNCR mapping can oops or panic the host via inconsistent nested MMU or sysreg state, and corrupting L1 EL2 control state or reused pages can hang or crash the hypervisor and co-resident nested guests; the attacker can retrigger the missed-invalidation sequence.
CVSS 3.1