CVE-2026-63941: KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Correctly cap ZCREL2 provided by a guest hypervisor
ZCREL2 can be updated by a VHE guest hypervisor either using ZCREL2 (which traps) or ZCREL1 (which does not trap). KVM handles both in different way:
- on ZCREL2 trap, ZCREL2.LEN is immediately capped at the VM's own VL limit. This has the potential to break existing SW that relies on the full LEN field to be stateful.
- on ZCREL1 access, we do absolutely nothing.
On restoring the SVE context for an L2 guest, we directly restore the guest hypervisor's view of ZCREL2 into the physical ZCREL2. If the guest's view of the register was updated using the ZCREL2 accessor, the value has already been sanitised (with the caveat mentioned above).
But if the guest used ZCREL1, the raw value is written into the HW, and the L2 guest can now access VLs that it shouldn't.
Fix all the above by moving the VL capping to the restore points, ensuring that:
- the HW is always programmed with a capped value, irrespective of the accessor being used,
- the ZCREL2.LEN field is always completely stateful, irrespective of the accessor being used.
Additionally, move ZCREL2 to be a sanitised register, ensuring that only the LEN field is actually stateful. This requires some creative construction of the RES0 mask, as the sysreg generation script does not yet generate RAZ/WI fields.
[maz: rewrote commit message, tidy up accesszcrel2()]
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In KVM arm64, move SVE vector-length capping to the restore points, ensure ZCR_EL2 is treated as a sanitised register, and cap the guest hypervisor's ZCR_EL2.LEN before restoring it to the physical register; keep only the LEN field stateful.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue affects arm64 KVM configurations involving a VHE guest hypervisor and an L2 guest that uses SVE. It concerns nested virtualization, where the guest hypervisor can update ZCR_EL2 through ZCR_EL1 or ZCR_EL2.
What does an attacker need to do to exploit it?
An attacker needs local, low-privileged access in the affected virtualization context. Exploitation relies on a VHE guest hypervisor setting its ZCR_EL2 view through the non-trapping ZCR_EL1 accessor, after which an L2 guest can access vector lengths beyond the VM's permitted limit.
How can I tell whether the vulnerable behavior is present?
The vulnerable behavior is present if an L2 guest's SVE context restoration writes an uncapped guest-hypervisor ZCR_EL2 value to physical hardware after that value was changed through ZCR_EL1. Systems without this VHE nested-virtualization and SVE scenario are not described as affected by the provided information.
What does the fix change?
The fix applies vector-length capping when restoring the relevant context rather than when ZCR_EL2 is accessed. This ensures hardware is programmed with a capped value regardless of whether the guest hypervisor used ZCR_EL1 or ZCR_EL2, while preserving the full ZCR_EL2.LEN field as guest state.