Skip to main content

Linux Kernel EUVDEUVD-2026-45714

| CVE-2026-63941 HIGH
2026-07-19 Linux GHSA-9mxh-6wp4-9v6p
8.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
8.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
vuln.today AI
2.8 LOW

Local guest-hypervisor privilege (AV:L/PR:L); AC:H due to required arm64 SVE nested-virt configuration; scope crosses VM boundary (S:C) with information-disclosure-only impact (C:L, I/A:N).

3.1 AV:L/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N
SUSE
HIGH
qualitative
Red Hat
7.0 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 20, 2026 - 16:27 vuln.today
CVSS changed
Jul 20, 2026 - 15:22 NVD
8.8 (HIGH)
Patch available
Jul 19, 2026 - 17:19 EUVD
CVE Published
Jul 19, 2026 - 14:55 cve.org
HIGH 8.8
CVE Published
Jul 19, 2026 - 14:55 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor

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:

  • on ZCR_EL2 trap, ZCR_EL2.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 ZCR_EL1 access, we do absolutely nothing.

On restoring the SVE context for an L2 guest, we directly restore the guest hypervisor's view of ZCR_EL2 into the physical ZCR_EL2. If the guest's view of the register was updated using the ZCR_EL2 accessor, the value has already been sanitised (with the caveat mentioned above).

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'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 ZCR_EL2.LEN field is always completely stateful, irrespective

of the accessor being used.

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.

[maz: rewrote commit message, tidy up access_zcr_el2()]

AnalysisAI

Improper vector-length capping in the Linux kernel's KVM arm64 SVE handling lets a nested (L2) guest under a VHE guest hypervisor access Scalable Vector Extension vector lengths beyond its configured limit. When a guest hypervisor updates ZCR_EL2 indirectly via the untrapped ZCR_EL1 accessor, KVM restores the raw value into the physical ZCR_EL2 without capping, breaking the vector-length confinement policy. There is no public exploit identified at time of analysis, and the EPSS probability is low (0.19%, 9th percentile); a vendor fix is available via the stable git tree.

Technical ContextAI

The flaw lives in KVM's Armv8 nested-virtualization (NV) support for the Scalable Vector Extension (SVE). On CPUs with SVE, ZCR_EL2.LEN caps the maximum vector length usable at EL2/EL1. A VHE guest hypervisor can program this either through ZCR_EL2 (which traps to KVM, where LEN was immediately capped to the VM's own VL limit) or through the aliased ZCR_EL1 (which does not trap and was previously ignored). When restoring the SVE context for an L2 guest, KVM wrote the guest hypervisor's stored ZCR_EL2 view straight into hardware; a value set via the untrapped ZCR_EL1 path was never sanitized, so the physical register could allow wider VLs than policy permits. The affected product per CPE is the Linux kernel (cpe:2.3:a:linux:linux). No CWE was assigned, but the root cause is an improper enforcement of an intended state/resource restriction (a state-confinement / improper input-validation class bug) combined with a non-stateful register field; the fix moves VL capping to the restore points and makes ZCR_EL2 a sanitised register where only LEN is stateful.

RemediationAI

Upstream fix available (stable git commits); a released patched tag should be confirmed against your distribution. Apply the stable-tree commits 742a9b5ccd8c46caf983ca90c94f855466968e34 and 83726330748981372bde86ed5411d7b306612991 (https://git.kernel.org/stable/c/742a9b5ccd8c46caf983ca90c94f855466968e34 and https://git.kernel.org/stable/c/83726330748981372bde86ed5411d7b306612991), or install the fixed kernel package from your distribution once it ships these backports. As a compensating control until patched, avoid enabling KVM nested virtualization on affected arm64 SVE hosts (do not expose EL2 to guests), which fully removes the attack surface at the cost of losing nested-virt functionality; where nested virt is required, restrict which tenants may run guest hypervisors, since the trade-off is operational rather than a code change. Given local access and guest privilege are prerequisites, tightening who can run untrusted nested-virt workloads meaningfully reduces exposure.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

EUVD-2026-45714 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy