Linux kernel (virt/kvm): KVM blocked turning KVM_MEM_GUEST_MEMFD on for an existing memslot but not turning it off, and

CVSS 7.8CVE-2025-68810Kernel, userspace & hypervisorcurated

Impact

KVM blocked turning KVM_MEM_GUEST_MEMFD on for an existing memslot but not turning it off, and clearing the flag left the guest_memfd binding in place. Releasing the file then writes through a stale pointer - a KASAN-confirmed slab use-after-free in host kernel memory, i.e. a kernel memory-corruption primitive for whoever can drive VM lifecycle ioctls.

Who can reach it

Not reachable from inside a guest. It is reached from the process holding the VM file descriptor via KVM_SET_USER_MEMORY_REGION2 with the guest_memfd flag cleared. The VMM is trusted here, so this matters on nodes where untrusted local users or tenant-run VMM processes can open /dev/kvm - there it is a local privilege-escalation primitive. guest_memfd is the backing store for confidential VMs (SEV-SNP / TDX), so confidential-compute nodes are the ones carrying this code.

What to do

Update to a stable kernel with the linked fix (no fixed release is enumerated; take the branch carrying commit 9935df5333aa). Interim control: keep /dev/kvm off tenant containers and restrict it to the operator's VMM service account; do not let tenants run their own VMM process on shared nodes.

References

https://git.kernel.org/stable/c/9935df5333aa503a18de5071f53762b65c783c4c https://git.kernel.org/stable/c/cb51bef465d8ec60a968507330e01020e35dc127 https://nvd.nist.gov/vuln/detail/CVE-2025-68810

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.