CVE-2026-52969

What it actually does

This is a Linux kernel KVM memory-corruption flaw in dirty-ring handling. A userspace virtual machine monitor with access to /dev/kvm can tamper with shared dirty-ring entries so that a 64-bit guest frame number offset wraps during bounds checking in kvm_reset_dirty_gfn(). Under affected KVM MMU conditions, especially shadow paging, allocated shadow roots, or write-tracked memory slots, the wrapped offset can reach rmap handling and cause an out-of-bounds load followed by a conditional write through an attacker-influenced pointer. The practical impact is local kernel memory corruption from a process that can create or control KVM VMs, with likely outcomes including host kernel crash and potential privilege escalation depending on kernel layout, hardening, and exploit reliability.

Why it matters to the business

Systems that run virtual machines on vulnerable Linux kernels could be destabilized or potentially compromised by a local user or workload that is allowed to use KVM. The most important operational risk is to virtualization hosts, CI runners, developer workstations, build infrastructure, and cloud or hosting nodes where untrusted users can launch KVM-backed virtual machines. Although this issue is not currently listed in CISA KEV, has no known mature public exploit in the provided data, and has a low EPSS score, the bug affects a highly privileged kernel component and should be prioritized on systems where /dev/kvm is exposed to untrusted or semi-trusted users.

How an attack unfolds

An attacker first needs local code execution in a context that can open /dev/kvm and act as a virtual machine monitor. The attacker creates or controls a KVM VM configured to use dirty-ring logging, then manipulates the MAP_SHARED dirty-ring backing memory exposed through the vCPU file descriptor. After the kernel writes dirty-ring entries, but before KVM_RESET_DIRTY_RINGS consumes them, the attacker rewrites entry payload fields such as slot and offset while relying on the flags handshake to appear valid. By crafting adjacent offsets so that dirty-ring coalescing creates a mask whose highest set bit causes unsigned addition to wrap, the attacker bypasses the intended memslot bounds check. The wrapped offset then propagates into KVM MMU dirty-log reset logic. On vulnerable MMU paths, this results in an out-of-bounds rmap access and a subsequent conditional page-table writable-bit modification through memory derived from the invalid rmap head, producing kernel memory corruption. Exploitation would likely require kernel-specific shaping and may be more reliable as a denial-of-service than as privilege escalation, but the primitive is security-significant because it occurs in kernel context.

How to fix it

Upgrade to a Linux kernel version that includes the fix for KVM dirty-ring offset validation in kvm_reset_dirty_gfn(), specifically the change that checks offset against memslot->npages before adding __fls(mask). If consuming a vendor kernel, apply the relevant distribution security update rather than relying only on upstream version numbers. Because no exact affected or fixed package versions were provided, track advisories from the Linux distribution or appliance vendor for CVE-2026-52969 and confirm the KVM patch is included. As interim mitigation, restrict access to /dev/kvm to trusted administrators and trusted virtualization services only, remove untrusted users from groups that grant KVM access, avoid running untrusted nested virtualization workloads, and consider disabling KVM or dirty-ring-based configurations on high-risk multi-user systems until patched. These mitigations reduce exploitability but do not correct the kernel defect.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package contains the KVM fix, not merely that a patched package is installed on disk. Reboot into the updated kernel where required. Validate with vendor advisory metadata, kernel changelog entries referencing rejection of wrapped offsets in kvm_reset_dirty_gfn(), or source/binary provenance showing that offset is range-checked before offset + __fls(mask). Inventory systems exposing /dev/kvm and prioritize those where non-root users or automation accounts can open it. Review permissions with commands such as ls -l /dev/kvm and group membership checks for users in kvm, libvirt, qemu, or equivalent virtualization groups. Where feasible, run a benign KVM workload after patching to ensure virtualization functionality remains operational, and monitor kernel logs for KVM, MMU, or page fault errors after rollout.

Typical attack path

1. Obtain local execution on a Linux host where the attacker can access /dev/kvm, commonly through membership in a virtualization-related group or through a service that launches KVM VMs.
2. Create or control a KVM virtual machine and vCPU using dirty-ring logging.
3. Map the dirty-ring memory shared by the vCPU file descriptor at KVM_DIRTY_LOG_PAGE_OFFSET.
4. Wait for or induce dirty-ring entries to be produced by KVM.
5. Rewrite dirty-ring entry slot and offset fields before KVM_RESET_DIRTY_RINGS consumes them.
6. Craft adjacent offsets so dirty-ring coalescing sets a high mask bit while the base offset is near U64_MAX.
7. Trigger KVM_RESET_DIRTY_RINGS so the unchecked offset plus mask calculation wraps and bypasses the memslot range check.
8. Reach the legacy/shadow MMU or write-tracked memslot path where the invalid guest frame number is used for rmap indexing.
9. Cause out-of-bounds kernel memory access and conditional modification of page-table-related memory.
10. Use the resulting corruption to crash the host kernel or attempt local privilege escalation.

How to detect it

Detection should focus on signs of attempted abuse by local processes with access to KVM and on kernel instability around the vulnerable code paths. Review auditd, eBPF, Sysmon-for-Linux, osquery, or endpoint telemetry for processes opening /dev/kvm and issuing KVM ioctls, especially VM monitor processes that are unexpected for the host role. If syscall auditing is enabled, examine ioctl activity against KVM file descriptors and correlate with process lineage, user identity, container context, and recent VM creation. Review kernel logs from journalctl, dmesg, persistent kmsg, netconsole, or crash dumps for oopses, panics, general protection faults, KASAN reports, or page faults involving KVM dirty-ring, MMU, rmap, or shadow paging functions. Investigate unexpected host reboots, hypervisor crashes, or VM monitor crashes occurring shortly after dirty-ring reset activity. Because exploitation is local and may leave limited application-layer traces, preserve vmcore/kdump output and kernel logs for any crash involving KVM. Threat-hunting should also look for newly introduced or suspicious binaries that open /dev/kvm outside approved hypervisor stacks such as qemu-system, libvirtd, virtqemud, or known orchestration agents.

• /dev/kvm
• KVM_RESET_DIRTY_RINGS
• KVM_DIRTY_LOG_PAGE_OFFSET
• kvm_reset_dirty_gfn
• kvm_dirty_ring_reset
• kvm_arch_mmu_enable_log_dirty_pt_masked
• gfn_to_rmap
• kvm_memslots_have_rmaps
• BUG: unable to handle page fault
• general protection fault
• kernel BUG at arch/x86/kvm
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• qemu-system-x86_64
• libvirtd
• virtqemud

What your security team should do

• Prioritize patching virtualization hosts, CI runners, developer machines, and any multi-user Linux systems where untrusted users can access /dev/kvm.
• Identify all systems with KVM enabled and enumerate which users, services, containers, or automation accounts can open /dev/kvm.
• Apply vendor kernel updates containing the KVM dirty-ring offset validation fix and reboot into the patched kernel.
• Until patched, restrict /dev/kvm permissions to trusted virtualization service accounts only and remove unnecessary users from KVM-related groups.
• Do not allow untrusted workloads to launch KVM-backed VMs or nested virtualization on vulnerable hosts.
• Increase monitoring for kernel crashes, KVM MMU faults, suspicious ioctl activity against /dev/kvm, and unexpected VM monitor processes.
• For containerized environments, ensure /dev/kvm is not passed into containers unless explicitly required and trusted.
• Treat unexplained host kernel oopses or panics involving KVM dirty rings, rmap, or MMU code as potential exploitation attempts and preserve forensic artifacts.