<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2026 21:10:12 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-63941 — KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-63941</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor&lt;/p&gt;
&lt;p&gt;ZCR_EL2 can be updated by a VHE guest hypervisor either using ZCR_EL2
(which traps) or ZCR_EL1 (which does not trap). KVM handles both in
different way:&lt;/p&gt;
&lt;p&gt;- on ZCR_EL2 trap, ZCR_EL2.LEN is immediately capped at the VM&amp;#39;s own
  VL limit. This has the potential to break existing SW that relies
  on the full LEN field to be stateful.&lt;/p&gt;
&lt;p&gt;- on ZCR_EL1 access, we do absolutely nothing.&lt;/p&gt;
&lt;p&gt;On restoring the SVE context for an L2 guest, we directly restore the
guest hypervisor&amp;#39;s view of ZCR_EL2 into the physical ZCR_EL2. If the
guest&amp;#39;s view of the register was updated using the ZCR_EL2 accessor,
the value has already been sanitised (with the caveat mentioned above).&lt;/p&gt;
&lt;p&gt;But if the guest used ZCR_EL1, the raw value is written into the HW,
and the L2 guest can now access VLs that it shouldn&amp;#39;t.&lt;/p&gt;
&lt;p&gt;Fix all the above by moving the VL capping to the restore points,
ensuring that:&lt;/p&gt;
&lt;p&gt;- the HW is always programmed with a capped value, irrespective of
  the accessor being used,&lt;/p&gt;
&lt;p&gt;- the ZCR_EL2.LEN field is always completely stateful, irrespective
  of the accessor being used.&lt;/p&gt;
&lt;p&gt;Additionally, move ZCR_EL2 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.&lt;/p&gt;
&lt;p&gt;[maz: rewrote commit message, tidy up access_zcr_el2()]&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor&lt;/p&gt;
&lt;p&gt;ZCR_EL2 can be updated by a VHE guest hypervisor either using ZCR_EL2
(which traps) or ZCR_EL1 (which does not trap). KVM handles both in
different way:&lt;/p&gt;
&lt;p&gt;- on ZCR_EL2 trap, ZCR_EL2.LEN is immediately capped at the VM&amp;#39;s own
  VL limit. This has the potential to break existing SW that relies
  on the full LEN field to be stateful.&lt;/p&gt;
&lt;p&gt;- on ZCR_EL1 access, we do absolutely nothing.&lt;/p&gt;
&lt;p&gt;On restoring the SVE context for an L2 guest, we directly restore the
guest hypervisor&amp;#39;s view of ZCR_EL2 into the physical ZCR_EL2. If the
guest&amp;#39;s view of the register was updated using the ZCR_EL2 accessor,
the value has already been sanitised (with the caveat mentioned above).&lt;/p&gt;
&lt;p&gt;But if the guest used ZCR_EL1, the raw value is written into the HW,
and the L2 guest can now access VLs that it shouldn&amp;#39;t.&lt;/p&gt;
&lt;p&gt;Fix all the above by moving the VL capping to the restore points,
ensuring that:&lt;/p&gt;
&lt;p&gt;- the HW is always programmed with a capped value, irrespective of
  the accessor being used,&lt;/p&gt;
&lt;p&gt;- the ZCR_EL2.LEN field is always completely stateful, irrespective
  of the accessor being used.&lt;/p&gt;
&lt;p&gt;Additionally, move ZCR_EL2 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.&lt;/p&gt;
&lt;p&gt;[maz: rewrote commit message, tidy up access_zcr_el2()]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-63941</guid>
    </item>
  </channel>
</rss>
