VMLAUNCH or VMRESUME.The CVE record, published by kernel.org and added to NVD on August 8, 2026, identifies the affected code as
arch/x86/kvm/vmx/nested.c. Its practical target is narrow: Intel VMX hardware, KVM’s
kvm-intelmodule, and nested virtualization where an L1 guest itself launches an L2 guest. A conventional Windows Server Hyper-V host is outside this path, as are ordinary Linux KVM guests that do not run nested VMX workloads.
The important operational detail is that the leak happens when KVM correctly rejects an invalid attempted L2 entry but fails to clean up state it acquired while preparing that entry. If the L1 hypervisor retries the operation, the leaked references can accumulate. That makes this a host-stability and capacity-management flaw first, even though it has been assigned a CVE and should be handled through normal security maintenance.
The failure path is a nested KVM corner case
Nested virtualization adds a third layer to the usual host-and-guest arrangement. The physical machine runs the L0 hypervisor, an L1 virtual machine runs its own hypervisor, and the L1 launches an L2 guest. KVM’s nVMX implementation is the Intel-specific code that lets an L1 guest use VMX instructions such as
VMLAUNCHand
VMRESUME.
Before allowing the L2 guest to run, KVM has to construct and validate a virtual VMCS — the Virtual Machine Control Structure that describes CPU state and execution controls. In this implementation,
vmcs12is the L1-visible VMCS representation. KVM may map or pin several guest-backed pages while processing it, including APIC-access, virtual-APIC, and posted-interrupt descriptor mappings.
According to the kernel.org CVE description, the bug appears when KVM synthesizes a nested VM exit because the L2 guest state is invalid during emulation of
VMLAUNCHor
VMRESUME. The normal
nested_vmx_vmexit()cleanup routine cannot be used in that exact branch because it is reserved for cases where L2 is actively running. Instead, the affected code used an open-coded equivalent of the exit path — and omitted the part that releases the
vmcs12pages.
The patch’s purpose is straightforward: execute the same page-unmap and unpin cleanup when an invalid-state failure prevents the nested VM entry from completing. The kernel mailing-list work that introduced the shared helper shows that KVM treats the APIC-access mapping, virtual APIC mapping, and posted-interrupt descriptor mapping as a group of resources that must be released together when nested execution ends or fails.
That detail changes the severity discussion. The problem is not that KVM accepts an invalid L2 guest. It does the opposite: it rejects it. The defect is that an error path does not return all the resources acquired before that rejection.
Retrying the bad launch is what turns a leak into an operational problem
A single failed VM entry may retain only a small number of mappings or page pins. The exposure grows when the L1 hypervisor keeps retrying an invalid
VMLAUNCHor
VMRESUME, because each unsuccessful cycle can repeat the missed cleanup. In a long-lived host, pinned pages are more consequential than ordinary transient allocations: they can resist reclaim and create misleading memory-pressure symptoms.
The CVE description specifically calls out “pinned pages (and/or mappings)” if L1 retries the operation. That is the strongest indicator that administrators should treat this as more than a cosmetic accounting bug. Depending on the workload and the invalid-state trigger, the visible symptoms could be steadily rising unreclaimable memory, worsening consolidation ratios, or an eventual host-level out-of-memory event rather than an immediate crash.
There is no public evidence, as of August 9, 2026, that CVE-2026-68081 has been exploited in the wild, and NVD has not assigned CVSS 4.0, CVSS 3.x, or CWE metadata. Those omissions matter. They mean security teams should avoid inventing a remote-attack narrative from a newly assigned identifier, while still patching hosts that actually expose the configuration.
The configuration requirement also supplies a clean temporary mitigation. Hosts that do not need nested virtualization can disable it through the
kvm-intel.nestedsetting, which kernel documentation identifies as the KVM/VMX nested-virtualization control and enables by default. Turning it off affects L1 guests’ ability to run L2 VMs, so it is a containment measure for selected hosts — not a blanket change for clusters running nested lab, CI, cloud, or appliance workloads.
Intel nVMX is affected; AMD nSVM is not this CVE
The vulnerable file is in KVM’s Intel VMX implementation. That excludes AMD’s separate nested-SVM, or nSVM, implementation from CVE-2026-68081’s stated scope. It also excludes KVM deployments using AMD hardware for their nested workloads, though administrators should not interpret that as a general statement about the security posture of nested virtualization.
The distinction is especially relevant in mixed fleets. A virtualization team may run the same guest images across Intel and AMD nodes while enabling nesting for only a subset of instances. Asset inventory needs to identify the host CPU vendor and whether
kvm_intelnesting is active; looking solely at whether KVM is installed will overstate the affected population.
Windows-centric administrators should make an equally sharp distinction. Windows 11, Windows Server, Hyper-V, and the Windows Subsystem for Linux do not become affected merely because they are associated with virtualization. The code at issue belongs to the Linux kernel’s KVM Intel nested-VMX implementation. A Windows workload can be involved only indirectly — for example, if it is an L2 guest running under an L1 hypervisor inside a Linux KVM guest — but the remediation belongs on the Linux L0 KVM host.
The Linux kernel documentation also states that KVM does not emulate invalid L2 guest state in the same way it can emulate invalid state for a non-nested guest. That behavior helps explain why this defect is tied to a synthesized nested VM exit: the invalid L2 entry needs to be reported to L1, and the cleanup must happen while KVM returns control to that L1 hypervisor.
The version data needs interpretation, not blind automation
NVD’s newly published record lists Linux 5.2 and later as affected before fixes, but its version encoding is awkward enough that administrators should not use the CVE page alone as a package decision engine. The record identifies three fixed commit references and marks Linux 6.18.40, Linux 7.1.5, and Linux 7.2-rc4 as unaffected points. That strongly indicates fixes were carried into two stable lines and mainline, but it does not create a universal “upgrade to this upstream number” rule for distribution kernels.
Enterprise distributions routinely backport KVM fixes to much older-looking version strings. AlmaLinux’s published kernel-rt source changelog, for example, shows the same “Put vmcs12 pages if nested VM-Enter fails due to invalid guest state” change in its
4.18.0-553.147.1.rt7.488.el8_10package stream on July 23, 2026 — more than two weeks before NVD published CVE-2026-68081. The patch title is there, but the changelog entry does not attach the CVE number, illustrating why a scanner that matches only upstream version numbers or CVE-labelled advisories can miss a backport.
That is the record’s material gap: NVD names upstream fix points but provides no distribution advisory matrix, no CVSS assessment, no exploit status, and no ready-made mapping to Red Hat, Ubuntu, SUSE, Debian, Proxmox, or cloud-provider kernel packages. The correct remediation test is whether the vendor kernel advisory or changelog contains the fix or one of the listed upstream commit backports — not whether
uname -rappears numerically newer than 6.18.40 or 7.1.5.
What KVM operators should do now
Teams running ordinary KVM workloads without nested virtualization can treat this as a routine kernel-update item. Teams operating nested CI runners, virtualized Kubernetes nodes that host VMs, appliance test beds, or cloud platforms that permit nested guests should prioritize it because their workload is capable of repeating the precise failure condition.
- Confirm whether
kvm_intelis loaded and whether nesting is enabled on each Linux virtualization host. - Identify L1 guests that run a nested hypervisor or depend on Intel VMX passthrough.
- Install the vendor-provided kernel update that incorporates the nVMX cleanup fix, then reboot or otherwise place the updated kernel into service.
- If patching must wait, disable nested KVM only on hosts where L2 workloads can be stopped without breaking services.
- Validate package changelogs and vendor advisories instead of relying on upstream release numbers, particularly on enterprise distributions with long-term kernel backports.
CVE-2026-68081 is a narrow defect, but it sits in exactly the kind of configuration where errors are often retried automatically and memory behavior is hardest to attribute: a hypervisor running inside another hypervisor. For operators using Intel nested KVM, the actionable conclusion is simple: patch the host kernel or disable nesting until the vendor kernel contains the cleanup, because a rejected L2 launch should not be able to leave host pages pinned behind it.
References
- Primary source: NVD / Linux Kernel
Published: August 9, 2026 at 8:02 AM UTC
- Security advisory: MSRC
Published: August 9, 2026 at 8:02 AM UTC
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: kernel.googlesource.com
- Related coverage: kernel.googlesource.com
- Related coverage: git.zx2c4.com
- Related coverage: git.zx2c4.com
- Related coverage: kernel.org
