dbcve.org
VulnerabilityAwaiting classification

CVE-2026-63941

HIGH · 8.8 CVSS v3.1 Published 2026-07-19
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
90/100
Remediation priority · Urgent
Zero-click 5 weeks old

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
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()]

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

A vulnerability in KVM arm64 allows a guest hypervisor (L2) to access SVE vector lengths beyond its allocated limit. When ZCR_EL2 is updated via ZCR_EL1 (non-trapping accessor), KVM writes the raw unsanitized value directly to hardware during L2 context restoration, bypassing the VL capping that occurs for ZCR_EL2 (trapping) accesses. This enables privilege escalation where an L2 guest can access vector lengths it shouldn't.

MitigationApply the kernel patch that moves VL capping to restore points and makes ZCR_EL2 a sanitized register with only the LEN field stateful; ensure all affected kernels receive the update.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Local
Complexity
Low
Privileges
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Confirm ARM64 architecture
    Check /proc/cpuinfo or run 'uname -m' to verify the system is running on aarch64 architecture
    Affected if System is not ARM64 architecture (not affected)
  2. Verify KVM hypervisor is present
    Check for kvmarm module: 'lsmod | grep kvm' or check /dev/kvm exists. On arm64, also check for 'kvmarm' specifically via 'cat /proc/irq/*/spurious' or kvm stat
    Affected if No KVM hypervisor present on arm64 system (not affected)
  3. Check kernel version
    Run 'uname -r' to get kernel version. Compare against the version where the fix was applied (the fix moves VL capping to restore points and converts ZCR_EL2 to a sanitized register)
    Affected if Kernel version predates the fix and system uses VHE hypervisors (potentially affected)
  4. Verify VHE is enabled
    Check /proc/cpuinfo for 'vhe' flag or use 'kubectl get nodes' on systems with virtualization workloads. Also check via 'cat /sys/hypervisor/properties/arch' if available
    Affected if VHE (Virtualization Host Extension) is not present/enabled (not affected)
  5. Inspect ZCR_EL2 register configuration
    From host EL2, read ZCR_EL2 via 'mrs x0, ZCR_EL2' (requires privileged access). Verify the LEN field is properly capped when accessed via either ZCR_EL1 or ZCR_EL2 accessor
    Affected if ZCR_EL2 shows unexpected vector length values accessible from L2 guests (indicates vulnerability present)

User is affected if running an unpatched arm64 kernel with KVM and VHE enabled, where L2 guests can access unsanitized ZCR_EL2 vector lengths beyond their allocated limits.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

From vendor data
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Apply the kernel patch that moves VL capping to restore points and makes ZCR_EL2 a sanitized register with only the LEN field stateful; ensure all affected kernels receive the update.

Have this fixed Scoped from the published advisory
  • Consultation2.0 h
  • Implementation4.0 h
  • Testing6.0 h
  • Review / QA2.0 h
14.0 hours of engineering $2,380
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,808.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-63941 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-63941 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data