Linux Kernel EUVD-2026-45714

Requires the host to be arm64 with SVE support, running KVM with nested virtualization enabled, and the attacker must control a VHE guest hypervisor (L1) that manipulates the vector-length cap via the ZCR_EL1 alias instead of the trapping ZCR_EL2 register. Limiting factors: exploitation is local (AV:L) and requires guest-hypervisor privilege (PR:L, i.e. authenticated within the virtualization stack), no user interaction, and - critically - a non-default, uncommon deployment (arm64 KVM nested virt + SVE). On hosts without SVE, without nested virtualization, or on non-arm64 architectures the code path is unreachable, so this is not exploitable against default or typical KVM configurations.

The input CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, base 8.8) rates this High, driven largely by the scope change (S:C) crossing the guest/hypervisor boundary and full C/I/A impact. That impact profile appears inflated relative to the described behavior: the vendor tags this 'Information Disclosure' and the described effect is an L2 guest gaining access to vector lengths it should not - a confinement breach, not clearly a full-integrity or availability compromise. EPSS is low (0.19%, 9th percentile), there is no KEV listing and no POC referenced, and the vulnerable code path (KVM arm64 with nested virtualization AND SVE) is a narrow, emerging configuration. Net: a legitimate correctness/security fix worth patching in the normal stable-kernel cadence, but not an emergency - real-world exploitability is gated by a rare deployment scenario rather than the raw 8.8 score. Note the conflict to verify: CVSS marks C:H/I:H/A:H with S:C, while the description and vendor tag point to information disclosure only; treat the high impact metrics with skepticism pending vendor clarification.

An attacker who controls a guest hypervisor (L1) on a vulnerable arm64 SVE host programs the vector-length cap through the untrapped ZCR_EL1 accessor rather than ZCR_EL2, then launches or resumes an L2 guest. On SVE context restore the un-sanitized value is written to the physical ZCR_EL2, letting the L2 guest use vector lengths beyond its intended limit and access SVE register state it should not. No public POC is referenced, and exploitation requires the attacker to already run privileged code inside a nested-virtualization stack.