Linux Kernel EUVD-2026-80516

Requires an arm64 host running KVM with nested virtualization support (FEAT_NV2 / VNCR fixmap path) enabled, and an attacker who already controls a guest with at least two concurrently-running vCPUs. Exploitation depends on winning a narrow race window between invalidate_vncr_va() on one vCPU and a VNCR translation fault-in on another vCPU (one vCPU updates S1 page tables and issues TLBI S1E2 while the other is mid-walk). Limiting factors: local access via a guest vCPU only (no remote/network path), timing-dependent race that is not deterministically triggerable, and the requirement for the rarely-deployed arm64 nested-virtualization feature - most arm64 KVM deployments do not enable NV and are unaffected.

This is a genuine but low-real-world-priority host-availability bug, and the vendor CVSS of 9.3 materially over-states it. The description is unambiguous that the flaw is a race condition (CWE-362) in KVM arm64's VNCR TLB invalidation path: invalidate_vncr_va() failed to bump mmu_invalidate_seq, so one vCPU can insert a TLB entry for a translation another vCPU just invalidated via S1E2 TLBI. This is a wrong-translation/TLB-corruption problem, not a controlled read/write primitive. The provided CVSS vector (AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) contains two clear errors: PR:N is wrong because triggering the race requires an already-running guest vCPU issuing faults and TLBIs (that is at least PR:L), and AC:L understates a timing-dependent inter-vCPU race window (realistically AC:H). C:H/I:H are also overstated - a stale/invalid TLB entry most plausibly yields crash/incorrect execution (DoS-dominant), with at most bounded integrity impact. There is no EPSS score, no KEV listing, and no public POC in the provided data, and the affected code path (arm64 nested virtualization / FEAT_NV2 VNCR) is very rarely deployed. Net: real bug worth patching on affected NV-enabled arm64 KVM hosts, but not a widespread-exploitation priority. My independent estimate is roughly 6.x, not 9.3.

A malicious or buggy L1 guest running on an arm64 KVM host with nested virtualization (FEAT_NV2/VNCR) enabled runs code on two vCPUs simultaneously: one faults in a VNCR translation while the other updates the stage-1 page tables and issues a TLBI S1E2 for the same VA. Winning this narrow timing window causes the host to install a stale/invalid VNCR TLB entry, corrupting translation and destabilizing the host. No public exploit code is identified in the provided data, and the local, race-dependent nature makes reliable exploitation difficult.