In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Correctly cap TLBI Range to the architural limit
TLB Invalidation by Range has a fairly powerful way of encoding pretty
large ranges in a small number of bits. This range can be based on an
arbitrary VA, which means it is pretty easy for a guest to generate an
overflow should the hypervisor be naive enough to add the range to the
base...
Make sure the range is capped to the limit dictated by the address bit
that determines the VA range. For an IPA invalidation, this is further
corrected down the line to ignore the upper range.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H
CVSS Score: 7.9
AV:L - A nested arm64 guest reaches decode_range_tlbi() by executing a range TLBI (RVAE/RIPAS2 and related encodings) that traps through kvm_handle_sys_reg into handle_tlbi_el2/handle_ripas2e1is; this is local KVM vCPU execution via /dev/kvm, not a network, adjacent, or physical path.
AC:L - Once nested virt is available (kvm-arm.mode=nested and KVM_ARM_VCPU_HAS_EL2), the guest fully controls the TLBI operand and can deterministically encode a base+range that overflows the VA half-space; no race or attacker-uncontrollable timing is required.
PR:L - The attacker must run code in a nested-capable KVM guest or create such a VM through /dev/kvm (typically kvm-group). That is low privilege relative to the host; the emulated TLBI path does not require init-namespace root.
UI:N - After the nested VM is running, exploitation is triggered solely by the guest executing the range TLBI; no additional host-user or victim action is required.
S:C - The bug is in KVM’s nested-virtualization TLB/VNCR handling: an L1 TLBI is misapplied by L0, so host-maintained VNCR and related nested MMU state is not invalidated, crossing the guest/hypervisor security boundary.
C:L - A wrapping range causes missed VNCR invalidation, so L0 may keep using a stale guest page for EL2 sysreg state and expose that bounded nested-hypervisor data to a page L1 believed unmapped (for example reused by L2). This is not an arbitrary host-memory read.
I:L - The host may keep writing nested EL2 sysreg state through the stale VNCR mapping into a guest page that should have been invalidated, corrupting bounded nested-virt state rather than providing an arbitrary host write or control-flow hijack.
A:H - Failed range invalidation leaves stale nested translations that can crash or hang the nested hypervisor or L2 workload, and the guest can repeat the TLBI at will, which is a complete availability loss for that nested VM.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
Low |
| Privileges Required |
Low |
Integrity Impact |
Low |
| User Interaction |
None |
Availability Impact |
High |
AV:L - A nested arm64 guest reaches decode_range_tlbi() by executing a range TLBI (RVAE/RIPAS2 and related encodings) that traps through kvm_handle_sys_reg into handle_tlbi_el2/handle_ripas2e1is; this is local KVM vCPU execution via /dev/kvm, not a network, adjacent, or physical path.
AC:L - Once nested virt is available (kvm-arm.mode=nested and KVM_ARM_VCPU_HAS_EL2), the guest fully controls the TLBI operand and can deterministically encode a base+range that overflows the VA half-space; no race or attacker-uncontrollable timing is required.
PR:L - The attacker must run code in a nested-capable KVM guest or create such a VM through /dev/kvm (typically kvm-group). That is low privilege relative to the host; the emulated TLBI path does not require init-namespace root.
UI:N - After the nested VM is running, exploitation is triggered solely by the guest executing the range TLBI; no additional host-user or victim action is required.
S:C - The bug is in KVM’s nested-virtualization TLB/VNCR handling: an L1 TLBI is misapplied by L0, so host-maintained VNCR and related nested MMU state is not invalidated, crossing the guest/hypervisor security boundary.
C:L - A wrapping range causes missed VNCR invalidation, so L0 may keep using a stale guest page for EL2 sysreg state and expose that bounded nested-hypervisor data to a page L1 believed unmapped (for example reused by L2). This is not an arbitrary host-memory read.
I:L - The host may keep writing nested EL2 sysreg state through the stale VNCR mapping into a guest page that should have been invalidated, corrupting bounded nested-virt state rather than providing an arbitrary host write or control-flow hijack.
A:H - Failed range invalidation leaves stale nested translations that can crash or hang the nested hypervisor or L2 workload, and the guest can repeat the TLBI at will, which is a complete availability loss for that nested VM.
CVSS 3.1