CVE-2026-63941

What it actually does

This is a Linux kernel KVM vulnerability on arm64 systems involving nested virtualization and Scalable Vector Extension state handling. A guest hypervisor can update ZCR_EL2-equivalent state through an access path that is not trapped and sanitized, causing KVM to restore an uncapped vector length value into the physical ZCR_EL2 register for an L2 guest. In affected configurations, this can allow a nested guest context to access vector lengths outside the limit intended for the virtual machine, breaking KVM isolation assumptions and potentially enabling local privilege escalation, information disclosure, memory corruption, or host/guest instability.

Why it matters to the business

Organizations running ARM64 Linux virtualization hosts with KVM, especially those allowing nested virtualization or untrusted users to run VMs, could face compromise of workload isolation. Successful exploitation could let an attacker with limited local or guest-level privileges affect data confidentiality, integrity, and availability beyond the intended VM boundary. The issue is newly published, has low current EPSS, is not listed in CISA KEV, and has no known public exploit maturity in the provided data, but the high CVSS impact means exposed virtualization platforms should still be prioritized for kernel updates during the next urgent maintenance window.

How an attack unfolds

An attacker first needs local execution capability in a relevant KVM virtualization context, such as control of a guest or nested guest environment on an affected ARM64 host where SVE and nested virtualization behavior are exposed. The attacker configures or runs a guest hypervisor that manipulates ZCR_EL2 state through the ZCR_EL1 access path, avoiding the sanitization that occurs on the trapped ZCR_EL2 path. When KVM later restores SVE context for an L2 guest, the guest-supplied raw vector length value can be written into hardware without being capped to the VM's configured vector length limit. The attacker then attempts to use the unauthorized vector length behavior to violate isolation, corrupt state, disclose data, escalate privileges, or crash the host or guest. There is no indication from the supplied intelligence that this is currently used by named threat actors, ransomware campaigns, or broad exploitation campaigns.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the KVM arm64 fix for correctly capping ZCR_EL2 at restore points and sanitizing ZCR_EL2 state. No exact affected package list or fixed version was provided, so use vendor advisories, kernel changelogs, and package metadata to identify the first fixed kernel for each platform. Prioritize ARM64 KVM hosts, especially those with SVE-capable CPUs and nested virtualization enabled. If immediate patching is not possible, reduce exposure by disabling nested virtualization for untrusted workloads, restricting access to /dev/kvm to trusted administrators and service accounts only, avoiding placement of untrusted VMs on affected ARM64 hosts, and disabling SVE exposure to guests where supported and operationally acceptable. Mitigations should be treated as temporary; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm that each ARM64 KVM host is running a vendor kernel build that includes the fix for KVM arm64 ZCR_EL2 restore-time vector length capping. Validate package versions against distribution security advisories or inspect kernel source/build metadata for the relevant KVM arm64 SVE/ZCR_EL2 patch. Reboot into the fixed kernel or confirm live patch applicability if supported. Verify exposure reduction by checking whether nested virtualization is disabled where not required, whether only trusted users can access /dev/kvm, and whether untrusted workloads are not scheduled on unpatched ARM64 KVM hosts. Functional validation should include starting representative VMs after patching and confirming KVM workloads operate normally without SVE or nested virtualization regressions.

Typical attack path

1. Obtain low-privileged local access or guest-level execution on an affected ARM64 KVM virtualization host.
2. Run or control a nested virtualization scenario involving a guest hypervisor and an L2 guest.
3. Manipulate SVE vector length control state through the ZCR_EL1 access path so the value is not trapped and capped by KVM at write time.
4. Trigger KVM to restore SVE context for the L2 guest, causing the uncapped ZCR_EL2 LEN value to be programmed into hardware.
5. Use the unauthorized vector length state to attempt isolation bypass, privilege escalation, memory corruption, information disclosure, or denial of service.

How to detect it

There are no reliable public, CVE-specific exploitation indicators in the supplied data, and exploitation would likely occur through low-level CPU register and KVM state manipulation that is not normally logged. To assess possible prior exploitation, review virtualization host telemetry for suspicious local access to KVM devices, unexpected nested virtualization enablement, newly created or unusual guest hypervisors, unexplained KVM or kernel crashes, and host instability around VM context switching. Relevant sources include kernel logs, hypervisor management logs, libvirt or equivalent virtualization orchestration logs, auditd records for /dev/kvm access, package/kernel upgrade history, VM lifecycle events, and EDR telemetry from virtualization hosts. Pay particular attention to untrusted users or workloads that gained access to KVM on ARM64 hosts before patching. Because no named threat actors or campaigns are associated in the provided data, detection should focus on anomalous use of KVM and nested virtualization rather than known actor tooling.

What your security team should do

• Inventory ARM64 Linux hosts running KVM and identify systems with SVE-capable CPUs, nested virtualization enabled, or untrusted VM workloads.
• Prioritize kernel patching for exposed virtualization hosts despite the low EPSS and absence from CISA KEV, because the potential impact crosses VM isolation boundaries.
• Restrict /dev/kvm access to trusted users and service identities; investigate any unexpected membership in virtualization-related groups such as kvm or libvirt.
• Disable nested virtualization for workloads that do not explicitly require it, especially on unpatched hosts.
• Move untrusted or multi-tenant workloads away from affected unpatched ARM64 KVM hosts until remediation is complete.
• Monitor kernel, hypervisor, and orchestration logs for abnormal KVM crashes, host instability, or unexpected nested virtualization activity.
• Track vendor advisories for exact fixed kernel versions and ensure golden images, templates, and autoscaling node images are rebuilt with the patched kernel.