Linux kernel pKVM on arm64: host-supplied __hyp_running_vcpu pointer dereferenced at EL2

CVSS 8.2CVE-2026-64286Kernel, userspace & hypervisorcurated

Impact

Under protected KVM on arm64, flush_hyp_vcpu() copied the host vCPU context into the hypervisor's private vCPU verbatim, including __hyp_running_vcpu, which EL2 code expects to be NULL for a guest context and otherwise resolves through container_of(). A compromised or malicious host kernel can therefore get a pointer of its choosing dereferenced at EL2 - inside the trust boundary pKVM exists to defend, which is exactly the boundary that makes confidential guests on arm64 meaningful. The scope change in the CVSS vector reflects that: the host escalates into the hypervisor. On arm64 accelerator hosts running confidential or isolated guests this undermines the isolation guarantee; on nodes not using pKVM there is no exposure. The fix clears __hyp_running_vcpu after the copy.

Who can reach it

Local, high privilege: the host kernel (EL1) attacking EL2 on an arm64 system running protected KVM. Not reachable from a guest, from an unprivileged host user, or remotely.

What to do

Update to a stable kernel containing the fix (five commits linked in the record) and reboot each affected arm64 host; a hypervisor-level fix cannot be applied without taking the node out of service. No fixed version numbers appear in the record. Hosts that do not enable pKVM are unaffected and can be patched on their normal cadence.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-64286 https://git.kernel.org/stable/c/477145860dba4c30f0b4e36f02f4c5291c1c888b https://git.kernel.org/stable/c/e8042f6e1d7befb2fb6b10a75918642bcd0acf9a

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.