Arm64 KVM flaw lets a guest VM reach into the host's memory
CVE-2026-89775 is a critical Linux kernel bug in the Arm64 virtualization path. A researcher says a guest can read and write host memory when nested virtualization is on.

Key points
- The Linux kernel flaw CVE-2026-89775 was published on 16 September 2026 and carries a critical CVSS score of 9.3.
- The bug sits in KVM, the Linux kernel's built-in engine for running virtual machines, on Arm64 processors, and only triggers when nested virtualization is in use.
- A researcher cited by The Hacker News says a guest VM can read and write host kernel memory and, from there, run code on the host itself.
- Red Hat's advisory says no mitigation currently meets its bar for ease of deployment, so patching the kernel is the fix.
- The fault is a mishandled negative value in a TLB size calculation when the guest's stage-1 MMU is switched off.
A critical bug in the Linux kernel can let a virtual machine reach into the memory of the physical server running it. Tracked as CVE-2026-89775 with a severity score of 9.3 out of 10, it affects Arm64 systems using KVM, the kernel's built-in engine for running virtual machines. It's the second KVM guest-escape we've reported in under seven weeks: our 6 August story covered Zapscape, CVE-2026-64561, a similar breakout from nested VMs.
On an affected host, a guest that should be sealed inside its own sandbox can read and change memory belonging to the host operating system. The researcher who reported the flaw, quoted by The Hacker News, says that's enough to break out of the guest and run arbitrary code on the host.
What is actually broken?
KVM has to keep track of small caches called TLBs, which help the processor translate memory addresses quickly. When a mapping changes, the kernel works out how big a chunk of that cache to discard.
The calculation assumes the guest's memory management unit, or MMU, is on. When it's off, KVM marks the level with a negative placeholder value. The helper function that reads that level didn't expect a negative number: it cast the value to an unsigned byte, looked at the bottom two bits, and produced an invalidation size of zero.
Zero means nothing gets cleaned up. Stale entries stay in the cache, and the guest ends up with a window into memory it should never see.
The fix rewrites the helper to handle negative levels properly and falls back to a full 1 GB invalidation when there's no valid level to read.
Who is exposed?
Arm64 Linux hosts running KVM with nested virtualization enabled, meaning hosts where a VM can run its own VMs inside it. That's a narrower slice than every Linux server, but it covers a growing share of Arm-based cloud instances and developer workstations.
Red Hat's write-up is blunt. Mitigation is either unavailable or doesn't meet its criteria for stability and ease of deployment. Update the kernel when your distribution ships the patch.
Should ordinary users worry?
Not directly. This is a server and cloud problem. If you rent Arm-based virtual machines from a cloud provider, the provider is the one patching the host underneath you.
The risk that matters for a customer is a noisy-neighbour scenario: a malicious tenant on the same physical machine using the flaw to reach data belonging to other tenants. That's exactly the shape of bug cloud operators treat as a drop-everything patch. Arm hypervisor escapes with a working proof of concept are rare, and this one will move fast.
What's worth saying plainly: the interesting thing here isn't sophisticated exploit tradecraft, it's how ordinary the underlying mistake is. A negative number cast to an unsigned type, a size that silently becomes zero, a security boundary quietly dissolved. These keep being found because they keep being there. Admins running Arm64 KVM hosts should track distribution kernel advisories this week and roll the update as soon as it lands.



