GPU VulnDB

Database/Kernel, userspace & hypervisor

KVM arm64: unvalidated FF-A offset lets the host kernel read and write past the hypervisor's memory-share buffer

CVSS 8.2CVE-2025-40266Kernel, userspace & hypervisorcurated

Impact

On arm64 hosts running protected KVM, the hypervisor runs at a higher privilege than the host kernel and is the thing that keeps guest memory out of a compromised host's reach. The FF-A memory-sharing path took an offset from the host without checking it, so a value near U32_MAX wraps the bounds arithmetic and gives out-of-bounds access inside the hypervisor's own FF-A buffer. That is a privilege boundary crossing in the wrong direction: code that was supposed to be contained by the hypervisor can reach hypervisor state. The practical relevance is Grace and other arm64 server hosts using pKVM for confidential or multi-tenant guests; on hosts not running pKVM, this path is not exercised.

Who can reach it

Local, from the host kernel itself - the CVSS vector records high privileges required, so the attacker must already be running privileged host-kernel code (a compromised host kernel or a kernel-level exploit chain). Not reachable from an unprivileged tenant process or from the network.

What to do

Take the stable kernel update that carries the offset check (four stable branches have the fix). On a GPU node this is the usual kernel rollout: drain the node, install the kernel, reboot, return it to the scheduler - there is no module reload or runtime mitigation for a pKVM code path. Hosts that do not enable protected KVM can treat this as low urgency and pick it up on the next regular kernel cycle.

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.