CVE-2026-89915

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

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:LAttack complexity, low

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:NPrivileges required, none

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:NUser interaction, none

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:CScope, changed

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:HConfidentiality impact, high

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:HIntegrity impact, high

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:HAvailability impact, high

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.