https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 05:36:58 +0000 https://vulnerability.circl.lu/vuln/cve-2026-72287 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into &#34;normal&#34; checks</p> <p>Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the &#34;normal&#34; controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM&#39;s value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM&#39;s CR3!</p> <p>Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a &#34;late&#34; flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn&#39;t a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn&#39;t want to run, i.e. when userspace is restoring/stuffing state.</p> <p>If reading guest memory fails, simply skip the consistency check, as KVM&#39;s de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into &#34;normal&#34; checks</p> <p>Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the &#34;normal&#34; controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM&#39;s value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM&#39;s CR3!</p> <p>Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a &#34;late&#34; flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn&#39;t a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn&#39;t want to run, i.e. when userspace is restoring/stuffing state.</p> <p>If reading guest memory fails, simply skip the consistency check, as KVM&#39;s de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.</p> https://vulnerability.circl.lu/vuln/cve-2026-72287