Arm Neoverse N1 / N2 / V1 / V2 / V3 / V3AE, Cortex-A76/A77/A78/A710, Cortex-X1-X925, C1-Ultra/Premium

Impact

A store issued on one core can land after another core has already invalidated the translation and completed its TLBI+DSB sequence. The write then commits through a stale translation into memory owned by a higher exception level - a guest writing into hypervisor memory, or a hypervisor writing into EL3/secure memory. In practice that is a write primitive into page tables and other memory-management structures you assumed were fenced off. Neoverse N1 is Ampere Altra and Graviton2; V1/V2 are Graviton3/Graviton4 and Grace. This is close to a worst case for a shared Arm host.

Who can reach it

Code running in a guest or in the host kernel on an affected Arm core, racing another core's TLB maintenance. Purely local, no device or network access needed, but it is a race, so exploitation needs control of scheduling on at least two cores - trivially satisfied by any tenant with more than one vCPU.

What to do

Requires coordinated firmware and OS updates, and you need both halves. TF-A platforms must build with WORKAROUND_CVE_2025_10263 enabled, which makes the affected TLBI+DSB sequences execute twice; the hypervisor and guest kernels need the matching arm64 errata workaround (Xen shipped XSA-493, Red Hat shipped a long errata chain). Flash + reboot + job drain on every node, and the OEM has to ship the BL31 build first. Ampere published AMP-SB-0008 for Altra and Altra Max. Expect a measurable cost on TLB-shootdown-heavy workloads because the barrier sequence is now doubled.

References