https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 03:38:06 +0000 https://vulnerability.circl.lu/vuln/bell-cve-2026-72287 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Withdrawn by the publisher.</strong></p> https://vulnerability.circl.lu/vuln/bell-cve-2026-72287 https://vulnerability.circl.lu/vuln/certfr-2026-avi-1229 certfr-2026-avi-1229 https://vulnerability.circl.lu/vuln/certfr-2026-avi-1229 https://vulnerability.circl.lu/vuln/fkie_cve-2026-72287 <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>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/fkie_cve-2026-72287 https://vulnerability.circl.lu/vuln/ghsa-2q48-vx2q-99r7 <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>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/ghsa-2q48-vx2q-99r7 https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-72287 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 115 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into &#34;normal&#34; checks 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! 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. 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> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 115 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into &#34;normal&#34; checks 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! 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. 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/ubuntu-cve-2026-72287 https://vulnerability.circl.lu/vuln/wid-sec-w-2026-2852 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.</p> https://vulnerability.circl.lu/vuln/wid-sec-w-2026-2852