GPU VulnDB

Database/Kernel, userspace & hypervisor

KVM arm64: guest hypervisor using ZCR_EL1 escapes its SVE vector-length cap on nested restore

CVSS 8.8CVE-2026-63941Kernel, userspace & hypervisorcurated

Impact

A VHE guest hypervisor can update ZCR_EL2 through ZCR_EL2 (which traps and was capped) or through ZCR_EL1 (which does not trap and was not handled at all). On SVE context restore for an L2 guest, KVM wrote the guest hypervisor's raw view into the physical ZCR_EL2, so a guest that used the ZCR_EL1 accessor got vector lengths beyond its configured limit. The fix moves capping to the restore points and makes ZCR_EL2 a sanitised register so only the LEN field is stateful. On an Arm host running nested virtualization this is a guest escaping a configured hardware limit - state confusion across the L1/L2 boundary rather than a demonstrated host-memory read. It is Arm64-only and only reachable where nested virtualization is in use, which is a narrow slice of accelerator fleets.

Who can reach it

A guest hypervisor (L1) on an Arm64 KVM host with nested virtualization enabled, writing ZCR_EL1. Requires running a VM on the host; no remote path and nothing reachable from a plain non-nested guest or from a host without SVE.

What to do

Update the host kernel to a stable release with the restore-point capping (three stable commits linked) and reboot each Arm64 KVM host; KVM core changes are not hot-patchable. x86 hosts and hosts that do not enable nested virtualization are unaffected, so most fleets can fold this into normal kernel maintenance. The record carries no vendor advisory with fixed version strings.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.