GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux KVM arm64: page-table walks without kvm->srcu can race memslot changes

CVSS 8.8CVE-2026-53277Kernel, userspace & hypervisorcurated

Impact

walk_s1() and kvm_walk_nested_s2() must run under kvm->srcu so the memslot array cannot change underneath them, but __kvm_at_s12() and __kvm_find_s1_desc_level() called them without taking it. A guest that drives the AT (address translation) emulation or fault-injection paths while the VMM updates memslots can race the walker against a freed or replaced memslot, which is a use-after-free class bug in host kernel context - NVD rates it local, low-privilege, with scope change and full host impact. This only affects arm64 KVM hosts, so it matters on Grace-class and other Arm GPU nodes that run tenant VMs, and is irrelevant on x86 hosts and on nodes that do not run KVM at all. Where it does apply the blast radius is the hypervisor, so one tenant VM on a shared Arm GPU host is the starting position.

Who can reach it

Local: a guest running on an arm64 KVM host, i.e. any tenant who can boot a VM on that node. No host credentials needed; not reachable over the network and not reachable on hosts that do not expose KVM to tenants.

What to do

Take the stable kernel fix (commits 9770609, ec42b4e, f2ca45b) or the distro update - Red Hat ships it as RHSA-2026:64775 - then drain each affected arm64 hypervisor node and reboot into the new kernel. There is no configuration mitigation inside KVM; the practical interim step is to not schedule untrusted tenant VMs on unpatched arm64 hosts. x86-only fleets can skip the maintenance window entirely.

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.