Files
vuln-cve/data/2026/72xxx/CVE-2026-72287.json
T

138 lines
8.5 KiB
JSON

{
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"cveMetadata": {
"cveId": "CVE-2026-72287",
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"state": "PUBLISHED",
"assignerShortName": "Linux",
"dateReserved": "2026-08-09T03:40:39.917Z",
"datePublished": "2026-08-15T05:55:09.624Z",
"dateUpdated": "2026-08-17T05:42:22.571Z"
},
"containers": {
"cna": {
"providerMetadata": {
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux",
"dateUpdated": "2026-08-17T05:42:22.571Z"
},
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks\n\nMove the off-by-default consistency check for vmcs12.tpr_threshold vs.\nthe virtual APIC vTPR into the \"normal\" controls checks, as waiting until\nKVM has loaded some amount of state is unnecessary and actively dangerous.\nSpecifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT\nis disabled results in KVM running L1 with an L1-controlled CR3, not with\nKVM's CR3!\n\nAlternatively, KVM could simply reset the MMU to force a reload of\nvmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a \"late\"\nflow was to wait until the vmcs12 pages were retrieved. Rather than build\nup more crusty code, simply access vTPR using a regular guest memory access\n(performance isn't a concern). To circumvent the restrictions that led to\nKVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read\nguest memory so that it always hits non-SMM memslots (for RSM), and (b)\nskip the check (since its off-by-default anyways) when the vCPU doesn't\nwant to run, i.e. when userspace is restoring/stuffing state.\n\nIf reading guest memory fails, simply skip the consistency check, as KVM's\nde facto ABI is that VMX instruction accesses to non-existent memory get\nPCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then\nthe vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD."
}
],
"metrics": [
{
"cvssV3_1": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"baseScore": 7.8,
"baseSeverity": "HIGH"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The bug is reached when an L1 nested-hypervisor guest executes VMLAUNCH/VMRESUME, driving KVM nested VM-Enter handling during KVM_RUN; no network, adjacent-radio, or physical-access path reaches this nVMX code.\nAC:H - Exploitation requires host EPT disabled (enable_ept=0) and the off-by-default developer warn_on_missed_cc module parameter; both are non-default host settings the attacking guest cannot enable, even though VMCS12/vAPIC fields are attacker-controlled once present.\nPR:L - The attacker needs ring-0 inside an L1 guest VM with nested VMX available (a typical nested-virt cloud tenant running its own hypervisor); no init-namespace host root or CAP_SYS_ADMIN on the host is required beyond ordinary VM execution.\nUI:N - Once nested virtualization is available, the malicious L1 hypervisor triggers the flaw solely via its own VMX instructions and crafted VMCS12/virtual-APIC state; no separate victim user action is required.\nS:C - Failure to restore vmcs01.GUEST_CR3 after the late VM-Fail leaves KVM running L1 with L1-controlled paging instead of KVM shadow CR3, crossing the guest/hypervisor isolation boundary in the classic KVM nested VMX guest-to-host escape class.\nC:H - Running L1 with its own CR3 under shadow paging (EPT disabled) lets the guest use attacker-chosen page tables to read host physical memory and kernel data outside its memslots, yielding arbitrary host information disclosure.\nI:H - The same CR3 confusion gives L1 arbitrary control over host physical mappings, enabling modification of host kernel structures and potential host code execution rather than a benign, correctly unwound VM-Fail.\nA:H - Beyond VM escape, inconsistent host CR3/paging state can oops or panic the host kernel when KVM resumes L1, denying availability to all co-resident VMs on the hypervisor."
}
]
}
],
"affected": [
{
"product": "Linux",
"vendor": "Linux",
"defaultStatus": "unaffected",
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"programFiles": [
"arch/x86/kvm/vmx/nested.c"
],
"versions": [
{
"version": "1100e4910ad207bc00aedc8dfdb228dd1b81f310",
"lessThan": "7d066368f72e6192af7e21c5817626f6da666991",
"status": "affected",
"versionType": "git"
},
{
"version": "1100e4910ad207bc00aedc8dfdb228dd1b81f310",
"lessThan": "ebdac7554abb347ca4197be241116842161acd9b",
"status": "affected",
"versionType": "git"
}
]
},
{
"product": "Linux",
"vendor": "Linux",
"defaultStatus": "affected",
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"programFiles": [
"arch/x86/kvm/vmx/nested.c"
],
"versions": [
{
"version": "6.19",
"status": "affected"
},
{
"version": "0",
"lessThan": "6.19",
"status": "unaffected",
"versionType": "semver"
},
{
"version": "7.1.5",
"lessThanOrEqual": "7.1.*",
"status": "unaffected",
"versionType": "semver"
},
{
"version": "7.2",
"lessThanOrEqual": "*",
"status": "unaffected",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.19",
"versionEndExcluding": "7.1.5"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.19",
"versionEndExcluding": "7.2"
}
]
}
]
}
],
"references": [
{
"url": "https://git.kernel.org/stable/c/7d066368f72e6192af7e21c5817626f6da666991"
},
{
"url": "https://git.kernel.org/stable/c/ebdac7554abb347ca4197be241116842161acd9b"
}
],
"title": "KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into \"normal\" checks",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
}
}