Linux Kernel KVM CVE-2026-53345

Exploitation requires local access to a Linux host with AMD EPYC hardware, the KVM kernel module loaded and SEV-ES support enabled, and user-level permissions to open /dev/kvm and create VMs (typically membership in the 'kvm' group or equivalent). The vulnerable condition is triggered specifically when: (1) an SEV-ES guest executes a VM-Exit that causes KVM to retain a writable guest page mapping, and (2) the controlling userspace process terminates without issuing a subsequent KVM_RUN ioctl. Normal VM lifecycle (including graceful shutdown with KVM_RUN calls) does not trigger the leak. Systems without AMD EPYC hardware, systems not running KVM, or systems not using SEV-ES guest configurations are entirely unaffected. The limiting factors - hardware specificity, SEV-ES configuration requirement, and the need for abnormal VM termination - substantially reduce real-world exploitability beyond what the CVSS AV:L/PR:L vector alone suggests.

CVSS 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) correctly reflects a local, low-privilege vector with no confidentiality or integrity impact, but high availability impact from the memory leak. EPSS 0.16% at the 5th percentile confirms very low real-world exploitation probability. There is no CISA KEV listing and no public proof-of-concept. The attack requires not only local access but also the ability to create and manage KVM VMs with SEV-ES - a capability requiring AMD EPYC hardware, kernel KVM support, and typically elevated or delegated virtualization permissions, making the PR:L designation generous. Practically, this affects cloud providers and enterprises running AMD-based KVM hypervisors; consumer Linux systems are unaffected. The CVSS S:U (unchanged scope) is consistent: the leak is in the host kernel but does not cross into guest trust boundaries. The tag 'Information Disclosure' in source metadata appears incorrect - the CWE (401) and CVSS impact metrics (C:N/I:N/A:H) confirm this is a memory leak / availability issue only; no information disclosure is described or implied.

A local user with permissions to create and manage KVM virtual machines on an AMD EPYC host configures an SEV-ES guest, runs it until a VM-Exit occurs that causes KVM to retain a writable guest page mapping, then terminates the VM management process without issuing a subsequent KVM_RUN call. On vCPU teardown, KVM's dirty page tracking path leaks the retained mapping, gradually consuming host kernel memory. Repeated VM creation and abnormal termination cycles could exhaust host memory, triggering an availability impact on the hypervisor host. No public exploit or proof-of-concept has been identified.