CVE-2026-53345

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Don&amp;#39;t WARN if memory is dirtied without a vCPU when the VM is dying<br /> <br /> When marking a page dirty, complain about not having a running/loaded vCPU<br /> if and only if the VM is still alive, i.e. its refcount is non-zero. This<br /> will allow fixing a memory leak for x86 SEV-ES guests without hitting what<br /> is effectively a false positive on the WARN.<br /> <br /> For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page<br /> across an exit to userspace, and typically unmaps the page on the next<br /> KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM<br /> needs to unmap the page when the vCPU is destroyed, which in turn triggers<br /> the WARN about not having a running vCPU.<br /> <br /> Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN,<br /> as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons;<br /> suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But<br /> loading a vCPU during destruction is gross (ideally nVMX code would be<br /> cleaned up), risks complicating the SEV-ES code (KVM would need to ensure<br /> the temporarily load()+put() only runs when the vCPU isn&amp;#39;t already loaded),<br /> and is ultimately pointless.<br /> <br /> The motivation for the WARN is to guard against KVM dirtying guest memory<br /> without pushing the corresponding GFN to the active vCPU&amp;#39;s dirty ring, e.g.<br /> to ensure userspace doesn&amp;#39;t miss a dirty page. But for the VM&amp;#39;s refcount<br /> to reach zero, there can&amp;#39;t be _any_ userspace mappings to the dirty ring,<br /> as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if<br /> userspace had a valid mapping for the dirty ring, then the vCPU file and<br /> thus the owning VM would still be alive. And so since userspace can&amp;#39;t<br /> possibly reach the dirty ring, whether or not KVM technically "misses" a<br /> push to the dirty ring is irrelevant.