CVE-2025-68810

What it actually does

Failure to reject memslot updates that clear KVM_MEM_GUEST_MEMFD on an existing binding leaves KVM still attached to the guest_memfd file, resulting in a use-after-free when kvm_gmem_release is later invoked on the freed backing structure.

Why it matters to the business

Linux hosts running KVM workloads face kernel memory corruption that can produce guest or host crashes, denial of service, or potential local privilege escalation; the issue affects any virtualized environment using guest_memfd-backed memory regions until patched kernels are deployed.

How an attack unfolds

An attacker with the ability to issue KVM_SET_USER_MEMORY_REGION ioctls first allocates a memslot with the KVM_MEM_GUEST_MEMFD flag, then issues a subsequent FLAGS_ONLY update that clears the flag; KVM performs the update without unbinding from guest_memfd, so a later close or exit triggers kvm_gmem_release on already-freed memory.

How to fix it

Upgrade the Linux kernel to a version that contains commit 89dbbe6ff323fc34659621a577fe0af913f47386 or later; rebuild and reboot all affected hosts; until the update can be applied, restrict unprivileged access to /dev/kvm via SELinux, AppArmor, or cgroup device filters.

How to confirm the fix worked

Confirm the running kernel contains commit 89dbbe6ff323fc34659621a577fe0af913f47386 by checking /proc/version or the package changelog; attempt to reproduce the original reproducer and verify that KVM now returns EINVAL when clearing KVM_MEM_GUEST_MEMFD on an existing memslot.

Typical attack path

1. Obtain capability to open /dev/kvm and create a VM with guest_memfd support
2. Issue KVM_SET_USER_MEMORY_REGION with KVM_MEM_GUEST_MEMFD set
3. Issue a second KVM_SET_USER_MEMORY_REGION ioctl that clears only the KVM_MEM_GUEST_MEMFD flag
4. Trigger process exit or file close to invoke kvm_gmem_release on the stale reference
5. Observe KASAN use-after-free or exploit the freed slab object for code execution

How to detect it

Review kernel logs for KASAN reports referencing kvm_gmem_release or slab-use-after-free during KVM memslot operations; inspect audit logs for repeated KVM_SET_USER_MEMORY_REGION ioctls from untrusted processes; no persistent artifacts remain after reboot.

What your security team should do

• Prioritize patching of all KVM hosts within the next maintenance window
• Audit systems for custom kernels or out-of-tree KVM modules that may still contain the vulnerable code
• Apply least-privilege controls on /dev/kvm access for non-administrative users
• Monitor vendor and distribution advisories for backported fixes in supported LTS kernels