In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Sign-extend VA for range-based TLBI invalidation
When the decode_range_tlbi() helper was moved to be used for S1 TLBIs,
the required sign extension was omitted. Add it.
As a result, special care must be taken to not overflow PA bits when
this is used for S2 invalidation.
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 - A nested arm64 L1 hypervisor reaches decode_range_tlbi() by executing a range TLBI (RVAE2/RVAE1/RIPAS2 and variants) that traps via ESR_ELx_EC_SYS64 into kvm_handle_sys_reg during KVM_RUN. This is local guest execution, not a network, adjacent-radio, or physical-device path.
AC:L - An L1 guest fully controls the TLBI Xt encoding (BASEADDR/TG/NUM/SCALE) and can deterministically hit the missing sign-extension for canonical high VAs. Nested virt and FEAT_TLBIRANGE on arm64 cloud hosts are attacker-selectable deployments, not an uncontrollable race or rare kernel config.
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_EL2 setup, S1 page-table updates, and EL2 range TLBIs are fully attacker-driven from the guest.
S:C - Missed high-VA VNCR invalidation leaves the host per-CPU PAGE_KERNEL fixmap covering a stale guest HPA while KVM emulates nested EL2 register state, crossing the guest-to-hypervisor security boundary (Changed per CNA KVM guidance).
C:H - Without sign_extend64(base, 48), range TLBIs for canonical high GVAs never match vt->gva, so the VNCR pseudo-TLB retains the old HPA; host KVM then reads that physical page through the kernel fixmap during sysreg emulation, disclosing whatever now backs that HPA.
I:H - kvm_map_l1_vncr() installs a writable PAGE_KERNEL fixmap of the stale HPA when S1 write permissions allow, so nested EL2 register writes land in pages the guest already rebound, giving a write primitive against host-managed physical memory.
A:H - Accessing an unmapped or reused HPA through the VNCR fixmap can oops or panic the host kernel, and corrupting emulated EL2 state or leaving stale nested translations can hang or crash the hypervisor and co-resident VMs; the attacker can retrigger the range TLBI.
| 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 - A nested arm64 L1 hypervisor reaches decode_range_tlbi() by executing a range TLBI (RVAE2/RVAE1/RIPAS2 and variants) that traps via ESR_ELx_EC_SYS64 into kvm_handle_sys_reg during KVM_RUN. This is local guest execution, not a network, adjacent-radio, or physical-device path.
AC:L - An L1 guest fully controls the TLBI Xt encoding (BASEADDR/TG/NUM/SCALE) and can deterministically hit the missing sign-extension for canonical high VAs. Nested virt and FEAT_TLBIRANGE on arm64 cloud hosts are attacker-selectable deployments, not an uncontrollable race or rare kernel config.
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_EL2 setup, S1 page-table updates, and EL2 range TLBIs are fully attacker-driven from the guest.
S:C - Missed high-VA VNCR invalidation leaves the host per-CPU PAGE_KERNEL fixmap covering a stale guest HPA while KVM emulates nested EL2 register state, crossing the guest-to-hypervisor security boundary (Changed per CNA KVM guidance).
C:H - Without sign_extend64(base, 48), range TLBIs for canonical high GVAs never match vt->gva, so the VNCR pseudo-TLB retains the old HPA; host KVM then reads that physical page through the kernel fixmap during sysreg emulation, disclosing whatever now backs that HPA.
I:H - kvm_map_l1_vncr() installs a writable PAGE_KERNEL fixmap of the stale HPA when S1 write permissions allow, so nested EL2 register writes land in pages the guest already rebound, giving a write primitive against host-managed physical memory.
A:H - Accessing an unmapped or reused HPA through the VNCR fixmap can oops or panic the host kernel, and corrupting emulated EL2 state or leaving stale nested translations can hang or crash the hypervisor and co-resident VMs; the attacker can retrigger the range TLBI.
CVSS 3.1