In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into "normal" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the "normal" 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's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM'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 "late" 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'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't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM'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.
AI Analysis
Technical Summary
The vulnerability in the Linux kernel KVM nested virtualization (nVMX) involved deferring the consistency check between vmcs12.tpr_threshold and the virtual APIC vTPR until a late stage, which was unnecessary and dangerous. Specifically, failure to properly unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled could result in KVM running the L1 guest with an L1-controlled CR3 instead of KVM's CR3. The fix moves this off-by-default consistency check into the normal control checks by accessing vTPR via regular guest memory access, skipping the check when the vCPU is not running, and handling read failures by skipping the check. This prevents the risk of running nested guests with incorrect memory management state.
Potential Impact
If exploited, the vulnerability could cause KVM to run nested guests with an incorrect CR3 register, potentially leading to incorrect memory management behavior within the virtualized environment. This could undermine the isolation guarantees of nested virtualization. However, no known exploits are reported in the wild, and the issue is related to internal consistency checks within KVM's nested virtualization implementation.
Mitigation Recommendations
A fix for this vulnerability has been implemented in the Linux kernel by moving the vTPR vs. TPR Threshold consistency check into the normal control checks. Users should apply the official Linux kernel updates that include this fix. Since no specific patch links or affected versions are provided, users should consult their Linux distribution or kernel vendor advisories for the relevant patched versions. No additional mitigations are indicated.
Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. (CVE-2026-72287)
Severity: critical
Type: Vulnerability
CVE: CVE-2026-72287
In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into "normal" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the "normal" 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's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM'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 "late" 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'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't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM'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.
Technical Summary
The vulnerability in the Linux kernel KVM nested virtualization (nVMX) involved deferring the consistency check between vmcs12.tpr_threshold and the virtual APIC vTPR until a late stage, which was unnecessary and dangerous. Specifically, failure to properly unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled could result in KVM running the L1 guest with an L1-controlled CR3 instead of KVM's CR3. The fix moves this off-by-default consistency check into the normal control checks by accessing vTPR via regular guest memory access, skipping the check when the vCPU is not running, and handling read failures by skipping the check. This prevents the risk of running nested guests with incorrect memory management state.
Potential Impact
If exploited, the vulnerability could cause KVM to run nested guests with an incorrect CR3 register, potentially leading to incorrect memory management behavior within the virtualized environment. This could undermine the isolation guarantees of nested virtualization. However, no known exploits are reported in the wild, and the issue is related to internal consistency checks within KVM's nested virtualization implementation.
Mitigation Recommendations
A fix for this vulnerability has been implemented in the Linux kernel by moving the vTPR vs. TPR Threshold consistency check into the normal control checks. Users should apply the official Linux kernel updates that include this fix. Since no specific patch links or affected versions are provided, users should consult their Linux distribution or kernel vendor advisories for the relevant patched versions. No additional mitigations are indicated.
Source: GCVE Database
Published: 08/15/2026
EPSS 0.1%top 97%
Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. (CVE-2026-72287)
In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into "normal" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the "normal" 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's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM'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 "late" 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'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't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM'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.
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
AILast updated: 08/15/2026, 16:43:13 UTC
Technical Analysis
The vulnerability in the Linux kernel KVM nested virtualization (nVMX) involved deferring the consistency check between vmcs12.tpr_threshold and the virtual APIC vTPR until a late stage, which was unnecessary and dangerous. Specifically, failure to properly unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled could result in KVM running the L1 guest with an L1-controlled CR3 instead of KVM's CR3. The fix moves this off-by-default consistency check into the normal control checks by accessing vTPR via regular guest memory access, skipping the check when the vCPU is not running, and handling read failures by skipping the check. This prevents the risk of running nested guests with incorrect memory management state.
Potential Impact
If exploited, the vulnerability could cause KVM to run nested guests with an incorrect CR3 register, potentially leading to incorrect memory management behavior within the virtualized environment. This could undermine the isolation guarantees of nested virtualization. However, no known exploits are reported in the wild, and the issue is related to internal consistency checks within KVM's nested virtualization implementation.
Mitigation Recommendations
A fix for this vulnerability has been implemented in the Linux kernel by moving the vTPR vs. TPR Threshold consistency check into the normal control checks. Users should apply the official Linux kernel updates that include this fix. Since no specific patch links or affected versions are provided, users should consult their Linux distribution or kernel vendor advisories for the relevant patched versions. No additional mitigations are indicated.
Pro Console: star threats, build custom feeds, automate alerts via Slack, email & webhooks.Upgrade to Pro
Technical Details
Gcve Source
db.gcve.eu
Osv Id
GHSA-2q48-vx2q-99r7
Osv Schema Version
1.4.0
Aliases
["CVE-2026-72287"]
Threat ID: 6a808b72bf8831d5394fcf7c
Added to database: 08/15/2026, 15:53:22 UTC
Last enriched: 08/15/2026, 16:43:13 UTC
Last updated: 09/30/2026, 06:54:40 UTC
Views: 51
Community Reviews
0 reviews
Crowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Sort by
Loading community insights…
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.