CVE-2026-63941

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor<br /> <br /> ZCR_EL2 can be updated by a VHE guest hypervisor either using ZCR_EL2<br /> (which traps) or ZCR_EL1 (which does not trap). KVM handles both in<br /> different way:<br /> <br /> - on ZCR_EL2 trap, ZCR_EL2.LEN is immediately capped at the VM&amp;#39;s own<br /> VL limit. This has the potential to break existing SW that relies<br /> on the full LEN field to be stateful.<br /> <br /> - on ZCR_EL1 access, we do absolutely nothing.<br /> <br /> On restoring the SVE context for an L2 guest, we directly restore the<br /> guest hypervisor&amp;#39;s view of ZCR_EL2 into the physical ZCR_EL2. If the<br /> guest&amp;#39;s view of the register was updated using the ZCR_EL2 accessor,<br /> the value has already been sanitised (with the caveat mentioned above).<br /> <br /> But if the guest used ZCR_EL1, the raw value is written into the HW,<br /> and the L2 guest can now access VLs that it shouldn&amp;#39;t.<br /> <br /> Fix all the above by moving the VL capping to the restore points,<br /> ensuring that:<br /> <br /> - the HW is always programmed with a capped value, irrespective of<br /> the accessor being used,<br /> <br /> - the ZCR_EL2.LEN field is always completely stateful, irrespective<br /> of the accessor being used.<br /> <br /> Additionally, move ZCR_EL2 to be a sanitised register, ensuring that<br /> only the LEN field is actually stateful. This requires some creative<br /> construction of the RES0 mask, as the sysreg generation script does<br /> not yet generate RAZ/WI fields.<br /> <br /> [maz: rewrote commit message, tidy up access_zcr_el2()]