GPU VulnDB

Database/Kernel, userspace & hypervisor

KVM arm64: hypervisor stack pages left in the host stage-2 mapping

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

Impact

On arm64 hosts running protected KVM, fix_host_ownership() walked only the linear-map alias of each memblock region. The per-CPU hyp stacks are mapped in the private VA range so they get a guard page and have no linear-map alias, so their pages were never taken out of the host stage-2 and the host kernel retained access to hypervisor stack memory. That undercuts the boundary pKVM exists to provide: a compromised host kernel can read and write the hypervisor's own stacks rather than being confined by stage-2. For operators this is the arm64 accelerator hosts - Grace-class and other Arm server nodes - where confidential or isolated guest VMs are sold on the assumption the host cannot reach hypervisor state. Exploitation requires privilege on the host already, so this is a defense-in-depth failure rather than a tenant-to-host break.

Who can reach it

Local with high privilege: code already running in the host kernel context on an arm64 node booted with protected KVM. Not reachable from a guest or from an unprivileged tenant process, and not applicable to x86 hosts.

What to do

Update to a stable kernel containing the fix, which walks each stack's private VA range with the same walker - commits 22df195bff84, 3a8c562892b9, e5dd2a91a7ae - then drain and reboot each affected arm64 host. There is no runtime mitigation: stage-2 ownership is established at hyp init, so a reboot onto the fixed kernel is the only fix. x86 fleets need no action.

References

Related entries

All Kernel, userspace & hypervisor entries

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.