CVE-2026-53345: Linux Kernel Privilege Escalation Flaw

CVE-2026-53345 Overview

CVE-2026-53345 affects the Linux kernel's Kernel-based Virtual Machine (KVM) subsystem. The issue triggers a false-positive WARN when guest memory is marked dirty without a running or loaded vCPU during virtual machine teardown. The condition specifically manifests with x86 Secure Encrypted Virtualization-Encrypted State (SEV-ES) guests. Maintainers resolved the flaw by only warning when the VM's refcount remains non-zero, which also unblocks a separate memory leak fix for SEV-ES.

Critical Impact
The defect produces spurious kernel warnings during SEV-ES VM destruction and blocks the resolution of a related memory leak in the KVM SEV-ES exit path.

Affected Products

Linux kernel KVM subsystem (x86)
SEV-ES guest execution paths
Stable kernel branches referenced by the upstream fix commits

Discovery Timeline

2026-07-01 - CVE-2026-53345 published to NVD
2026-07-01 - Last updated in NVD database

Technical Details for CVE-2026-53345

Vulnerability Analysis

The defect resides in KVM's dirty-page tracking logic. When KVM marks a guest page dirty, it emits a WARN if no vCPU is currently running or loaded. This guard exists to ensure that dirtied guest frame numbers (GFNs) are pushed to the active vCPU's dirty ring, so userspace does not miss a dirty page. The check misfires during VM teardown when SEV-ES guests must unmap pages that were left writable across an exit to userspace.

For certain SEV-ES VM-Exits, KVM retains a writable mapping of a guest page across a userspace exit. KVM normally unmaps that page on the next KVM_RUN. If userspace never issues another KVM_RUN before closing the vCPU file descriptor, KVM must unmap the page during vCPU destruction. That unmap path marks the page dirty without a loaded vCPU and trips the warning.

Root Cause

The root cause is an overly broad invariant in the dirty-tracking WARN. The check assumed that any dirtying operation must occur with a live vCPU context. It did not account for teardown paths where the VM is already being destroyed and no userspace consumer of the dirty ring can exist. Mapping the dirty ring requires mmap() on the vCPU file descriptor, so a zero VM refcount guarantees no reachable dirty-ring mapping.

Attack Vector

No remote or local attack vector is documented for this issue. The defect is a kernel self-diagnostic misfire during legitimate SEV-ES teardown sequences. Exploitability metadata is not published, and no proof-of-concept, exploit, or CISA KEV entry exists. The EPSS score reported at publication is 0.156%, consistent with a low likelihood of weaponization.

No verified public exploit code exists for this defect. See the upstream fix commits for the exact source-level change, including kernel commit 033d39e4 and kernel commit 99d7d437.

Detection Methods for CVE-2026-53345

Indicators of Compromise

Kernel log entries containing WARN messages emitted from KVM dirty-ring tracking during vCPU destruction.
Repeated warnings correlated with SEV-ES guest shutdowns on affected kernels.
Reports of unreclaimed guest memory tied to SEV-ES VM-Exits that never reached a subsequent KVM_RUN.

Detection Strategies

Monitor dmesg and journalctl -k output for KVM WARN_ON stack traces referencing dirty-page marking during VM destruction.
Correlate warnings with SEV-ES workload lifecycle events on hypervisor hosts.
Compare running kernel versions against the stable branches carrying the upstream fix commits.

Monitoring Recommendations

Forward hypervisor kernel logs to a centralized logging platform for pattern matching on KVM warning signatures.
Track memory consumption of qemu-kvm or equivalent processes hosting SEV-ES guests to identify residual leaks.
Alert on kernel taint flags becoming set after SEV-ES VM teardown.

How to Mitigate CVE-2026-53345

Immediate Actions Required

Apply the stable-tree kernel updates that include the KVM refcount-aware WARN fix.
Reboot hypervisor hosts running SEV-ES workloads after patching to load the corrected kernel.
Audit any custom KVM patches to confirm they do not reintroduce the broader WARN condition.

Patch Information

Upstream fixes are available in the Linux kernel stable trees. Reference the following commits: 033d39e4, 343e95c8, 66a8e7dd, 8618004d, and 99d7d437. The change restricts the dirty-tracking WARN to VMs whose refcount is still non-zero.

Workarounds

Avoid running SEV-ES guests on unpatched kernels where the associated memory leak is a concern.
Restart hypervisor hosts periodically to reclaim leaked pages until the fix is deployed.
Suppress non-security kernel warning noise from operational dashboards while preserving raw logs for forensic review.

bash

# Verify running kernel version and check for the fix commit in the source tree
uname -r
git -C /usr/src/linux log --oneline | grep -E '033d39e4|99d7d437|343e95c8|66a8e7dd|8618004d'