VULNERABILITY! A weakness is found that allows access from a virtual machine to the host system in Linux KVM/ARM64!
A serious security vulnerability has been found in the KVM/ARM64 virtualization mechanism of the Linux kernel. This vulnerability, reported as CVE-2026-89775, can allow an attacker inside a virtual machine to escape the VM boundary and affect its host system under certain conditions.
The problem is particularly significant in ARM64 KVM hosts that support nested virtualization—that is, the ability to run virtual machines within a virtual machine. Such environments are used in multi-tenant cloud infrastructures, test laboratories, and services that allow users to create virtual machines.
The vulnerability was disclosed by security researcher Hyunwoo Kim on September 17, 2026. According to the researcher's information, the problem is related to a type truncation error in the memory size calculation process within the Linux kernel's KVM/ARM64 code. A patch to fix this issue has already been introduced in the Linux mainline kernel.
What are KVM and ARM64?
KVM (Kernel-based Virtual Machine) is a virtualization technology installed in the Linux kernel that allows running multiple independent virtual machines on a single physical server.
Simply put, the physical server is the host, and the virtual computer running inside it is called the guest.
For example, multiple virtual machines can run simultaneously on a single ARM64 server:
Physical Server → KVM host → VM-1, VM-2, VM-3…
Normally, these virtual machines are isolated from each other and the host system. That is, a user inside one virtual machine should not be able to directly access another client's VM or the host operating system.
It is precisely this isolation boundary that can be at risk due to CVE-2026-89775.
What is Nested Virtualization?
Another important concept to understand this vulnerability is nested virtualization.
In simple virtualization, a virtual machine runs on a physical server. When nested virtualization is enabled, another virtual machines can also be run within the virtual machine.
That is:
Physical Server → KVM host → Guest VM → Inner VM
This capability can be useful for developing, testing, and utilizing cloud services and virtualization laboratories.
However, it complicates the interaction between the nested virtualization host and the guest. Therefore, security flaws in this capability can create additional conditions for escaping from the virtual machine to the host system.
CVE-2026-89775 poses a risk specifically for KVM/ARM64 hosts with nested virtualization enabled.
How does the vulnerability occur?
The problem is related to the process of managing virtual memory addresses and invalidating stale memory mappings in KVM/ARM64.
KVM uses various memory mappings and translations to manage the memory accesses of virtual machines. When a memory map changes or a specific memory page is freed, the corresponding memory translations must be invalidated to prevent the use of old information.
If this process does not work correctly, the virtual machine might continue to use stale information related to a previous memory address.
The problem in CVE-2026-89775 occurs in certain stages of this process.
According to the researcher's information, the type change error that occurs during the traversal of the KVM/ARM64 stage-1 page table leads to an incorrect calculation of the memory region size. The calculated value might be 0. In reality, this value should imply the indeterminacy of memory size.
However, the subsequent invalidation mechanism accepts this 0 value as the actual size.
As a result, the memory range that should be invalidated is interpreted as an empty range, and the necessary invalidation action is not performed.
What can happen as a result?
The problem becomes particularly serious here.
If the memory translation is not invalidated in time, old information related to a previously freed host memory page might be retained.
According to the researcher's information, in some conditions, the freed host memory page might remain mapped with the host kernel address.
After this, the malicious guest memory page might have the ability to read and write the freed host memory page at a 64-bit level. Importantly, this access might not trigger the expected trap or exit process from the virtual machine.
Simply put:
Guest VM → Memory management error in KVM → Unauthorized access to Host memory → Host security is compromised
This can violate one of the most important protection boundaries of virtualization.
What is Guest-to-Host Escape?
Guest-to-Host Escape is when an attacker inside a virtual machine escapes the virtual machine boundary and affects the main host operating system.
This is considered one of the most serious risks in a virtualization environment.
Because if a simple server is compromised, the attacker can control a single system. But if the security of the host system is compromised, the attacker can pose a threat to multiple virtual machines and services running on that host.
This situation is particularly important in multi-tenant cloud infrastructures where VMs of different clients run on a single physical server.
What is the Risk for Cloud Services?
CVE-2026-89775 is particularly important for multi-tenant cloud infrastructures based on ARM64.
Imagine a single physical server running virtual machines for multiple organizations.
Normally:
Client A VM → manages only its own VM
Client B VM → manages only its own VM
Host → manages all VMs
If an attacker inside a VM can make unauthorized access to the host memory, the isolation mechanism can be breached.
According to the researcher's report, an attacker can create virtual machines in a multi-tenant ARM64 cloud environment and gain a way to escape to the host system from there.
This situation poses a specific risk for cloud providers because if the host system is compromised, it can affect the security of other clients' virtual machines as well.
There is also a risk for local users.
The vulnerability is not limited to cloud environments.
Permissions can be extended to the /dev/kvm device in some Linux distributions and configurations. In the investigation, permissions for /dev/kvm with 0666 were recorded in some Red Hat Enterprise Linux configurations.
If nested virtualization is also enabled on such a host, an unprivileged local user might exploit this vulnerability to gain higher privileges on the host system.
Therefore, organizations must check not only the existence of KVM virtual machines but also:
- /dev/kvm permissions;
- the state of nested virtualization;
- the host kernel version;
- VM creation rights;
- users who can use KVM.
What code range is affected by the vulnerability?
According to the researcher's information, the vulnerable code was introduced into the Linux kernel via commit 7270cc9157f47 on May 14, 2025, and fixed via commit 8053393680d4 on August 6, 2026.
This information helps system administrators determine whether the vulnerability affects the kernel of their Linux distribution.
However, relying only on upstream commit dates is not enough in practice. Different Linux distributions may update the core with their own security fixes.
Therefore, administrators should check the security advisories and updates released by their distribution vendor as the primary source.
What measures should organizations take?
1. Update the Linux kernel
Check the version of the Linux kernel running on ARM64 KVM hosts and install the update that includes the fix for CVE-2026-89775 provided by the distribution vendor.
Updates should be prioritized for generally used or multi-tenant virtualization servers.
2. Evaluate the necessity of nested virtualization
If an organization does not need to use the nested virtualization feature, it is recommended to disable it.
This does not completely eliminate the vulnerability, but it can reduce the risk by removing one of the necessary conditions for this attack vector.
Note: This measure should not be seen as a substitute for security updates.
3. Check /dev/kvm permissions
On Linux hosts:
Check who can use the /dev/kvm device.
If access rights are granted to users who need more than access to the KVM device, these permissions should be reviewed.
This control is important on servers where unprivileged users have the ability to use KVM.
4. Restrict VM creation rights
In multi-tenant environments, check the rights of users to create new virtual machines, use nested virtualization, or access KVM interfaces.
The principle of least privilege should be followed: do not grant unnecessary privileges.
5. Inventory KVM hosts
Identify all ARM64 KVM hosts in the organization.
It is appropriate to create a separate list for the following:
- host name;
- Linux distribution and version;
- kernel version;
- KVM status;
- ARM64 platform;
- nested virtualization status;
- /dev/kvm permissions;
- number of virtual machines on the host;
- users with rights to create VMs.
This information helps in quickly identifying the scope of the vulnerability.
If there is a suspicion that the vulnerability has been exploited
If suspicious activity is detected on an ARM64 KVM host, it should not be limited to checking only the virtual machine. The host system itself should also be examined.
In other words:
- kernel logs;
- events related to KVM;
- unusual processes;
- unexpected root-level processes;
- new users;
- unusual connections via SSH;
- changes in system files;
- unexpected services;
- changes in virtual machine configurations
should be analyzed.
If there is a possibility that the host has been compromised, then the security of all virtual machines running on that host should also be separately assessed.
The vulnerability in the memory translation process in the Linux KVM/ARM64 environment can allow for the breaking of the security boundary between the virtual machine and the host.
The problem is particularly relevant for ARM64 KVM hosts with nested virtualization enabled and multi-tenant cloud infrastructures that allow users to create virtual machines for untrusted users.
The patch exists in the Linux mainline kernel. Therefore, organizations should install the security updates released for their distributions without delay, reconsider the need to use nested virtualization, and check the /dev/kvm permissions.
It is important to take into account that the compromise of a single guest VM's security can affect the security of the entire host and other virtual environments.
The fundamental principle of virtualization security is that the isolation between the guest and the host must always be strongly protected. Weaknesses in core infrastructure components like KVM can directly affect this protection boundary.