CVE-2026-53345

What it actually does

This is a Linux kernel KVM issue in the SEV-ES guest teardown path. Under specific VM lifecycle conditions, KVM can dirty or unmap a guest page after userspace has stopped running the vCPU and the VM is being destroyed. Older kernel logic treats that state as suspicious and emits a kernel WARN even though the dirty-ring state is no longer reachable by userspace. The practical security impact is denial of service on systems where kernel warnings are configured to panic the host, or operational degradation from repeated kernel warnings and noisy logs. Exploitation requires local ability to use KVM, and the issue is most relevant to hosts running AMD SEV-ES virtual machines.

Why it matters to the business

A user or workload with permission to create and control KVM virtual machines may be able to crash or destabilize a virtualization host if the host is configured to panic on kernel warnings. In cloud, hosting, CI, lab, or multi-tenant virtualization environments, this could interrupt guest workloads on the same host and create operational incidents. Public exploitation signals are currently low: the issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no known mature exploit, and has a very low EPSS score, but kernel DoS flaws should still be prioritized on shared virtualization infrastructure.

How an attack unfolds

An attacker first needs local access to a system where they can open /dev/kvm and create KVM virtual machines, typically through membership in a virtualization-capable group or access to a VM management service. They then create or control an AMD SEV-ES guest and drive it into a state where certain SEV-ES VM exits leave KVM holding a writable mapping to a guest page. Instead of resuming the vCPU with another KVM_RUN call, the attacker tears down the vCPU or VM. During destruction, KVM unmaps the page and marks it dirty while no running vCPU is loaded. Vulnerable kernels may emit a WARN for this path. If the host is configured with panic_on_warn, that warning can escalate into a kernel panic and host-level denial of service. Without panic_on_warn, the effect is usually limited to kernel log noise and potential monitoring alerts rather than full compromise.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the KVM fix for this issue. No exact package versions were provided in the input, so use vendor advisories, changelogs, or kernel stable release notes to identify the first fixed kernel for each supported platform. Prioritize virtualization hosts, systems exposing /dev/kvm to untrusted users, and hosts running AMD SEV-ES guests. If immediate patching is not possible, reduce exposure by restricting access to /dev/kvm and VM management APIs, disabling unneeded SEV-ES functionality, limiting untrusted local users from creating KVM guests, and reviewing whether kernel.panic_on_warn is enabled. Disabling panic_on_warn can reduce the chance that this warning becomes a host crash, but it should be treated as a risk tradeoff rather than a complete fix.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package or build includes the upstream or vendor KVM patch that suppresses the WARN when the VM refcount indicates the VM is dying. Reboot into the updated kernel after installation, because kernel updates are not effective until the fixed kernel is running. Check `uname -a`, distribution package metadata, and vendor security advisory status across virtualization hosts. Validate exposure reduction by confirming only trusted users and services can access /dev/kvm and that unneeded SEV-ES support is disabled where appropriate. Review `kernel.panic_on_warn` with `sysctl kernel.panic_on_warn`; a value of 1 increases DoS impact if the vulnerable warning is reachable. Regression testing should include creating and destroying SEV-ES guests and confirming no related KVM WARN appears in kernel logs during vCPU teardown.

Typical attack path

1. Obtain local access to a Linux host or management path that allows creation or control of KVM virtual machines.
2. Confirm access to /dev/kvm and, for the most relevant path, the ability to run AMD SEV-ES guests.
3. Create or manipulate a SEV-ES guest so that a VM exit causes KVM to keep a writable mapping of a guest page across the exit to userspace.
4. Avoid calling KVM_RUN again after the relevant VM exit.
5. Destroy the vCPU or VM, forcing KVM cleanup to unmap and dirty the page without an active loaded vCPU.
6. Trigger a kernel WARN in vulnerable kernels; if kernel.panic_on_warn is enabled, cause a host kernel panic and denial of service.

How to detect it

There are no network indicators for this issue because exploitation is local to a KVM-capable host. To determine whether it may have been triggered, review kernel logs from `dmesg`, journald, `/var/log/kern.log`, `/var/log/messages`, and crash dump infrastructure for WARN or panic events involving KVM, SEV-ES, vCPU destruction, dirty page handling, or VM teardown. Correlate any such events with VM management logs showing recent creation, running, exit, and destruction of SEV-ES guests, especially repeated patterns by the same user or service account. Audit logs can help identify local access to `/dev/kvm` and VM-control ioctls if syscall auditing was enabled. If `kernel.panic_on_warn=1`, also review kdump, pstore, IPMI/iDRAC/iLO event logs, and hypervisor host reboot records for crashes preceded by KVM warning traces. Absence of these artifacts does not prove non-exploitation, because a host panic may truncate logs unless persistent logging or crash capture was configured.

• /dev/kvm
• kernel.panic_on_warn = 1
• kernel.panic_on_warn=1
• WARNING: CPU:
• KVM
• SEV-ES
• KVM_RUN
• kvm_vcpu_unmap
• mark_page_dirty_in_slot
• kvm_release_pfn_dirty
• dirty ring
• vCPU
• VM-Exit
• panic_on_warn

What your security team should do

• Inventory Linux virtualization hosts using KVM, especially systems capable of running AMD SEV-ES guests.
• Patch affected hosts to a kernel version containing the KVM fix, prioritizing shared or multi-tenant virtualization infrastructure.
• Restrict /dev/kvm access to trusted users and service accounts only; remove unnecessary users from virtualization-capable groups.
• Review `kernel.panic_on_warn`; if enabled on exposed virtualization hosts, assess whether the operational DoS risk outweighs the diagnostic benefit until patching is complete.
• Search historical kernel logs for KVM WARN traces associated with SEV-ES guest teardown or vCPU destruction.
• Monitor for unusual VM lifecycle activity, including repeated create/destroy cycles of SEV-ES guests by the same local user or automation identity.
• Because this CVE is not in KEV and has very low EPSS, treat it as lower internet-wide exploitation priority but higher priority for organizations offering untrusted or semi-trusted KVM access.