CVE-2026-46082 is a newly published Linux kernel KVM vulnerability, disclosed by kernel.org and listed by NVD on May 27, 2026, that fixes AMD SVM emulation so INVLPGA correctly raises an invalid-opcode exception when EFER.SVME is disabled. That is a mouthful, but the practical story is simpler: this is a virtualization correctness bug that became a security record because correctness is security when hypervisors are involved. It is not, at least from the public record so far, another “drop everything” kernel disaster. It is a reminder that the most important bugs in modern infrastructure often hide in the tiny gap between what silicon promises and what software faithfully imitates.
The patch behind CVE-2026-46082 adds a permission check to KVM’s AMD SVM handling for
That sounds like a narrow architectural housekeeping fix because it is one. The public patch is only a few lines, and the CVE description does not describe a flashy exploit chain, privilege escalation recipe, or remote attack surface. NVD had not assigned a CVSS score at publication time, which is common for fresh kernel CVEs that have been reserved from upstream fixes before enrichment catches up.
But small patches in KVM deserve more attention than their line count suggests. KVM is the boundary layer between workloads that are supposed to be isolated from one another. When it emulates CPU behavior incorrectly, the bug is no longer just about whether a weird instruction returns the right exception; it is about whether a guest can observe or influence a state transition it should not be able to reach.
The relevant condition is
KVM’s job is to reproduce that contract for virtual machines. The bug fixed here is that KVM’s SVM path did not inject the invalid-opcode exception for
This is the kind of issue that makes kernel CVE triage frustrating for outsiders. There is no banner headline in the patch. There is no obvious “attacker gets root” sentence. Yet the fix sits in code whose whole purpose is to keep guest CPU state coherent, and coherence is one of the foundations of isolation.
That creates a different kind of burden for administrators. Ten years ago, a KVM patch like this might have been absorbed into a stable update with little fanfare outside virtualization maintainers. Today, it appears in vulnerability feeds, scanner dashboards, compliance reports, and customer questionnaires before NVD has even assigned severity.
The upside is that important infrastructure fixes are harder to miss. The downside is that not every CVE-shaped object carries the same operational urgency. CVE-2026-46082 is a good example of why security teams need to read the affected code path, not just the identifier.
The right interpretation is not “ignore it because it is obscure.” The right interpretation is “patch it through the normal kernel maintenance channel, and prioritize it more highly on hosts running AMD-based KVM workloads, especially nested virtualization.”
A Windows Server VM running on an AMD EPYC host may never know that KVM’s SVM code exists. The administrator patching Windows may never touch the host kernel. But the trust boundary under that Windows guest is Linux kernel code, and vulnerabilities in that layer affect the assurances the guest relies on.
The same applies to developers running Windows test images on Linux workstations, MSPs hosting customer desktops, and organizations using Proxmox, OpenStack, oVirt-derived stacks, or custom KVM fleets. If the host is AMD-based and exposes virtualization features to guests, this patch belongs in the normal update conversation.
This is also relevant to nested virtualization, where one hypervisor is run inside another. Nested virtualization is no longer an academic stunt. It underpins lab environments, security research, cloud testing, Android emulation, WSL-adjacent workflows in some setups, and platform engineering pipelines that need disposable hypervisors inside disposable guests.
Security teams should resist both reflexes here. One reflex is to panic because any CVE in a hypervisor sounds catastrophic. The other is to dismiss it because there is no score and no public exploit. Neither is useful.
The better question is exposure. Are you running affected Linux kernels on AMD hosts? Are those hosts using KVM? Do guests have access to nested SVM features or instruction paths where this behavior matters? Are the systems multi-tenant, internet-facing through hosted services, or part of a cloud control plane where guest isolation is the product?
For a single-user Linux desktop with virtualization installed but rarely used, this is probably background noise. For a hosting provider running AMD KVM nodes, it is a routine but real host-kernel update. For a cloud platform that permits nested virtualization, it is a correctness fix in a high-value boundary.
CPU vendors write architecture manuals full of these distinctions because real processors must behave predictably across privilege levels, modes, and feature combinations. Hypervisors then have to emulate enough of that behavior to convince operating systems, kernels, and nested hypervisors that they are running on coherent hardware.
That is brutally hard work. Most guest software follows normal paths, so obscure states may sit untested until someone writes conformance tests, fuzzes the interface, or runs into a nested virtualization quirk. When the failure is in instruction emulation, the difference between “allowed,” “intercepted,” and “invalid” can matter a great deal.
In this case, the corrected behavior is to inject
Still, KVM bugs deserve a conservative reading because the attack boundary is unusually important. If a guest can cause the host hypervisor to mishandle privileged architectural state, even in a narrow scenario, that can become a primitive for denial of service, information exposure, or a more subtle guest isolation problem. Not every correctness bug becomes an escape, but many serious escapes begin as correctness bugs.
The most plausible immediate impact here is guest-visible misbehavior rather than a clean host compromise. A guest executing
That distinction matters for risk language. Administrators should not advertise this as a confirmed guest-to-host escape unless later analysis proves it. They should also not shrug it off as merely cosmetic. A hypervisor’s job is to be boringly exact, and this patch fixes a place where it was not exact enough.
That matters because virtualization hosts tend to run conservative kernels. Enterprises do not move hypervisor fleets casually. They run distribution kernels, long-term support kernels, and vendor-tuned builds that may lag upstream by design.
The presence of stable references means the right fix is not to cherry-pick from a mailing list unless you build kernels for a living. The right fix is to wait for your distribution or platform vendor to ship the corresponding stable update, then roll it through the host fleet using the same process you use for other kernel updates.
For Proxmox, Debian, Ubuntu, Red Hat-family distributions, SUSE, Arch, and cloud images, the exact package name and timing will vary. What matters operationally is the host kernel, not the guest operating system. Updating Windows guests will not fix a KVM host bug.
A developer laptop running a couple of trusted VMs is not the same thing as a multi-tenant virtualization cluster. A lab host used by one administrator is not the same thing as a provider selling Windows VPS instances. A private CI runner that executes untrusted customer code inside nested virtualization deserves more attention than a dormant KVM install.
The common factor is guest control. If untrusted or semi-trusted users can run code inside guests on AMD-backed KVM hosts, then architectural emulation bugs become more interesting. Even if this CVE turns out to have limited exploitability, it sits in the part of the stack those users can prod.
Cloud providers have mature processes for this category of issue. Smaller shops often do not. They may patch guests aggressively while leaving hosts on old kernels because host reboots are disruptive and customer-visible. CVE-2026-46082 is a useful reminder that virtualization hosts are not infrastructure furniture; they are active security components.
AMD appears in the story because SVM is AMD’s virtualization architecture and
This is also why patch notes for hypervisors can look alien to ordinary vulnerability readers. They are full of acronyms that are not products, not brands, and not configuration switches an admin toggles in a GUI. They are the vocabulary of the CPU contract.
The practical translation is straightforward: if your KVM host is not using AMD SVM, this particular CVE is probably not your problem. If it is using AMD SVM, especially with nested virtualization or untrusted guests, it belongs on the host patch list.
That is where a medium-looking or unscored CVE can linger. It does not generate the urgency of a branded vulnerability. It does not break workloads in obvious ways. It waits in the gap between “we should patch hosts” and “we have a maintenance window.”
The best organizations treat host patching as part of capacity engineering, not as a panic ritual. They maintain enough spare capacity to evacuate nodes. They test live migration across kernel versions where applicable. They know which workloads cannot tolerate migration and need downtime communication.
CVE-2026-46082 is not likely to be remembered as a famous vulnerability. But it is exactly the sort of fix that separates well-run virtualization platforms from improvised ones. The technical change is small; the operational discipline around applying it is the real test.
The second step is checking vendor advisories and package updates. Distribution maintainers may fold the fix into broader kernel releases, and those releases may contain many unrelated changes. That is normal. Kernel security rarely arrives as a single isolated package with a neat label.
The third step is planning reboots. A patched kernel does not protect a host that has not booted into it. This remains one of the least glamorous truths in Linux security operations, and it matters especially for hypervisors where uptime pressure is intense.
Security teams should also tune their messaging. If the vulnerability feed shows CVE-2026-46082 but NVD has no score, explain that the record is awaiting enrichment and that the fix concerns KVM’s AMD SVM instruction handling. That is more useful than assigning an invented severity or forwarding the raw CVE text to an infrastructure team.
That changes testing and threat models. A nested guest can drive code paths that were once obscure, and cloud customers increasingly expect those paths to work. Developers want local labs that mirror production. Security teams want sandboxes inside sandboxes. Platform teams want ephemeral clusters that bring their own virtualization layers.
The KVM community has spent years improving nested SVM and nested VMX behavior because these use cases are real. But the more faithfully a hypervisor exposes virtualization to a guest, the more precisely it must enforce the conditions under which virtualization instructions are valid.
CVE-2026-46082 fits neatly into that story. It is not about a flashy new feature. It is about making the invalid path invalid, because nested virtualization leaves less room for hand-waving around “nobody should execute that anyway.”
Most Windows workloads will never directly exercise
For enterprise IT, the lesson is contractual as much as technical. Ask providers how they handle host kernel CVEs. Ask whether AMD KVM nodes are patched through rolling maintenance. Ask how nested virtualization is exposed and constrained. The details matter more than a marketing statement about “enterprise-grade isolation.”
For home lab users, the advice is simpler. If you run AMD-based KVM hosts, install kernel updates from your distribution and reboot into them. If you run Windows guests on that host, do not confuse guest Windows Update with host security maintenance.
A Three-Line Patch Lands in the Most Sensitive Part of the Stack
The patch behind CVE-2026-46082 adds a permission check to KVM’s AMD SVM handling for INVLPGA, an AMD virtualization instruction used to invalidate guest address translations. If the guest has not enabled Secure Virtual Machine support through EFER.SVME, the instruction should not behave like a valid virtualization operation. It should trigger #UD, the x86 invalid-opcode exception.That sounds like a narrow architectural housekeeping fix because it is one. The public patch is only a few lines, and the CVE description does not describe a flashy exploit chain, privilege escalation recipe, or remote attack surface. NVD had not assigned a CVSS score at publication time, which is common for fresh kernel CVEs that have been reserved from upstream fixes before enrichment catches up.
But small patches in KVM deserve more attention than their line count suggests. KVM is the boundary layer between workloads that are supposed to be isolated from one another. When it emulates CPU behavior incorrectly, the bug is no longer just about whether a weird instruction returns the right exception; it is about whether a guest can observe or influence a state transition it should not be able to reach.
The Bug Is About Architecture, Not Drama
INVLPGA is not a desktop user’s instruction. It belongs to the virtualization machinery used in AMD’s SVM architecture, the AMD-V world that KVM exposes and manages for guest systems. In plain English, it deals with invalidating cached address translations, the sort of invisible bookkeeping that keeps virtual memory and nested virtualization from becoming a swamp of stale mappings.The relevant condition is
EFER.SVME, a bit in AMD’s Extended Feature Enable Register. When that bit is not set, SVM instructions are not supposed to be available. If software tries to execute one anyway, the CPU contract says the instruction is invalid and should raise #UD.KVM’s job is to reproduce that contract for virtual machines. The bug fixed here is that KVM’s SVM path did not inject the invalid-opcode exception for
INVLPGA under the disabled-SVME condition. The fix adds a call into KVM’s nested SVM permission checking before proceeding with the instruction handling.This is the kind of issue that makes kernel CVE triage frustrating for outsiders. There is no banner headline in the patch. There is no obvious “attacker gets root” sentence. Yet the fix sits in code whose whole purpose is to keep guest CPU state coherent, and coherence is one of the foundations of isolation.
The CVE Process Is Now Catching Kernel Plumbing by Design
The presence of a CVE record for a bug this specific is not an accident. The Linux kernel project’s modern CVE handling has made it much more likely that fixes in security-sensitive subsystems will receive CVE identifiers, even when the public description is terse and the exploitability is not yet scored.That creates a different kind of burden for administrators. Ten years ago, a KVM patch like this might have been absorbed into a stable update with little fanfare outside virtualization maintainers. Today, it appears in vulnerability feeds, scanner dashboards, compliance reports, and customer questionnaires before NVD has even assigned severity.
The upside is that important infrastructure fixes are harder to miss. The downside is that not every CVE-shaped object carries the same operational urgency. CVE-2026-46082 is a good example of why security teams need to read the affected code path, not just the identifier.
The right interpretation is not “ignore it because it is obscure.” The right interpretation is “patch it through the normal kernel maintenance channel, and prioritize it more highly on hosts running AMD-based KVM workloads, especially nested virtualization.”
Why WindowsForum Readers Should Care About a Linux KVM CVE
This is WindowsForum, so it is fair to ask why a Linux kernel KVM bug matters to a Windows-heavy readership. The answer is that Windows estates increasingly run on Linux whether administrators asked for that abstraction or not. Cloud providers, CI systems, virtualization clusters, lab environments, and hybrid infrastructure routinely host Windows guests on Linux KVM.A Windows Server VM running on an AMD EPYC host may never know that KVM’s SVM code exists. The administrator patching Windows may never touch the host kernel. But the trust boundary under that Windows guest is Linux kernel code, and vulnerabilities in that layer affect the assurances the guest relies on.
The same applies to developers running Windows test images on Linux workstations, MSPs hosting customer desktops, and organizations using Proxmox, OpenStack, oVirt-derived stacks, or custom KVM fleets. If the host is AMD-based and exposes virtualization features to guests, this patch belongs in the normal update conversation.
This is also relevant to nested virtualization, where one hypervisor is run inside another. Nested virtualization is no longer an academic stunt. It underpins lab environments, security research, cloud testing, Android emulation, WSL-adjacent workflows in some setups, and platform engineering pipelines that need disposable hypervisors inside disposable guests.
The Absence of a Score Is Not a Clean Bill of Health
At the time the record appeared, NVD listed CVSS values as unavailable. That does not mean the bug is harmless. It means NVD had not completed enrichment, and the kernel CVE record itself did not ship with a fully developed severity narrative.Security teams should resist both reflexes here. One reflex is to panic because any CVE in a hypervisor sounds catastrophic. The other is to dismiss it because there is no score and no public exploit. Neither is useful.
The better question is exposure. Are you running affected Linux kernels on AMD hosts? Are those hosts using KVM? Do guests have access to nested SVM features or instruction paths where this behavior matters? Are the systems multi-tenant, internet-facing through hosted services, or part of a cloud control plane where guest isolation is the product?
For a single-user Linux desktop with virtualization installed but rarely used, this is probably background noise. For a hosting provider running AMD KVM nodes, it is a routine but real host-kernel update. For a cloud platform that permits nested virtualization, it is a correctness fix in a high-value boundary.
Hypervisors Fail at the Edges of the Spec
The interesting part of CVE-2026-46082 is not that a KVM maintainer added a check. It is that hypervisor bugs so often arise from edge-case architecture semantics: a bit not set, a mode not active, an instruction that should fault rather than proceed, a guest state that is legal to represent but illegal to execute through.CPU vendors write architecture manuals full of these distinctions because real processors must behave predictably across privilege levels, modes, and feature combinations. Hypervisors then have to emulate enough of that behavior to convince operating systems, kernels, and nested hypervisors that they are running on coherent hardware.
That is brutally hard work. Most guest software follows normal paths, so obscure states may sit untested until someone writes conformance tests, fuzzes the interface, or runs into a nested virtualization quirk. When the failure is in instruction emulation, the difference between “allowed,” “intercepted,” and “invalid” can matter a great deal.
In this case, the corrected behavior is to inject
#UD when INVLPGA is attempted without SVM enabled. That aligns the virtual CPU with the architectural rule. The fix is boring in the best possible way: it makes the guest see what real hardware should have made it see.The Security Impact Is Probably Narrow, but the Boundary Is Not
Public information does not currently support breathless claims of widespread exploitation. There is no disclosed proof of concept in the CVE text, no NVD score, and no vendor language suggesting emergency mitigation. The patch was routed through stable kernel channels, which indicates it is worth backporting but not necessarily that it is a five-alarm incident.Still, KVM bugs deserve a conservative reading because the attack boundary is unusually important. If a guest can cause the host hypervisor to mishandle privileged architectural state, even in a narrow scenario, that can become a primitive for denial of service, information exposure, or a more subtle guest isolation problem. Not every correctness bug becomes an escape, but many serious escapes begin as correctness bugs.
The most plausible immediate impact here is guest-visible misbehavior rather than a clean host compromise. A guest executing
INVLPGA in a state where SVM is disabled should be told “that instruction is invalid.” If KVM instead continues down the instruction path, it is deviating from the architecture in a place connected to address translation and nested virtualization.That distinction matters for risk language. Administrators should not advertise this as a confirmed guest-to-host escape unless later analysis proves it. They should also not shrug it off as merely cosmetic. A hypervisor’s job is to be boringly exact, and this patch fixes a place where it was not exact enough.
Stable Backports Show the Kernel Team Wants This Everywhere
The CVE references multiple stable kernel commits, which means this was not treated as a fix only for the newest development tree. Stable backporting is the kernel community’s way of saying the bug exists in maintained branches where users are expected to consume fixes without jumping to mainline.That matters because virtualization hosts tend to run conservative kernels. Enterprises do not move hypervisor fleets casually. They run distribution kernels, long-term support kernels, and vendor-tuned builds that may lag upstream by design.
The presence of stable references means the right fix is not to cherry-pick from a mailing list unless you build kernels for a living. The right fix is to wait for your distribution or platform vendor to ship the corresponding stable update, then roll it through the host fleet using the same process you use for other kernel updates.
For Proxmox, Debian, Ubuntu, Red Hat-family distributions, SUSE, Arch, and cloud images, the exact package name and timing will vary. What matters operationally is the host kernel, not the guest operating system. Updating Windows guests will not fix a KVM host bug.
The Most Exposed Systems Are the Ones That Sell Isolation
For many organizations, the vulnerable surface is not every Linux machine. It is the subset of Linux machines acting as a virtualization boundary for workloads they do not fully trust. That distinction should guide urgency.A developer laptop running a couple of trusted VMs is not the same thing as a multi-tenant virtualization cluster. A lab host used by one administrator is not the same thing as a provider selling Windows VPS instances. A private CI runner that executes untrusted customer code inside nested virtualization deserves more attention than a dormant KVM install.
The common factor is guest control. If untrusted or semi-trusted users can run code inside guests on AMD-backed KVM hosts, then architectural emulation bugs become more interesting. Even if this CVE turns out to have limited exploitability, it sits in the part of the stack those users can prod.
Cloud providers have mature processes for this category of issue. Smaller shops often do not. They may patch guests aggressively while leaving hosts on old kernels because host reboots are disruptive and customer-visible. CVE-2026-46082 is a useful reminder that virtualization hosts are not infrastructure furniture; they are active security components.
AMD-Specific Does Not Mean AMD Is at Fault
The bug is in Linux KVM’s handling of AMD SVM semantics, not an AMD hardware vulnerability based on the public record. That difference is important. The processor architecture defines the behavior; the hypervisor failed to reproduce one part of it correctly.AMD appears in the story because SVM is AMD’s virtualization architecture and
INVLPGA is part of that world. Intel systems use a different virtualization architecture, VMX, with different instruction semantics and different KVM code paths. That does not make one vendor’s CPUs inherently safer in this context; it means the bug is tied to the AMD-specific implementation path.This is also why patch notes for hypervisors can look alien to ordinary vulnerability readers. They are full of acronyms that are not products, not brands, and not configuration switches an admin toggles in a GUI. They are the vocabulary of the CPU contract.
The practical translation is straightforward: if your KVM host is not using AMD SVM, this particular CVE is probably not your problem. If it is using AMD SVM, especially with nested virtualization or untrusted guests, it belongs on the host patch list.
The Real Risk Is Operational Complacency
Kernel virtualization bugs often suffer from a visibility problem. They are too technical for executive dashboards, too low-level for application owners, and too disruptive for casual patching. Everyone agrees the host kernel matters; fewer organizations have a clean, tested, regularly exercised process for rebooting virtualization nodes without drama.That is where a medium-looking or unscored CVE can linger. It does not generate the urgency of a branded vulnerability. It does not break workloads in obvious ways. It waits in the gap between “we should patch hosts” and “we have a maintenance window.”
The best organizations treat host patching as part of capacity engineering, not as a panic ritual. They maintain enough spare capacity to evacuate nodes. They test live migration across kernel versions where applicable. They know which workloads cannot tolerate migration and need downtime communication.
CVE-2026-46082 is not likely to be remembered as a famous vulnerability. But it is exactly the sort of fix that separates well-run virtualization platforms from improvised ones. The technical change is small; the operational discipline around applying it is the real test.
The Patch Says Less Than the Fleet Inventory Does
For administrators, the first useful step is not reading every line of KVM’s SVM code. It is knowing where KVM runs, which hosts use AMD CPUs, and which kernels those hosts boot. Many organizations cannot answer those questions quickly, and that is more concerning than this particular CVE.The second step is checking vendor advisories and package updates. Distribution maintainers may fold the fix into broader kernel releases, and those releases may contain many unrelated changes. That is normal. Kernel security rarely arrives as a single isolated package with a neat label.
The third step is planning reboots. A patched kernel does not protect a host that has not booted into it. This remains one of the least glamorous truths in Linux security operations, and it matters especially for hypervisors where uptime pressure is intense.
Security teams should also tune their messaging. If the vulnerability feed shows CVE-2026-46082 but NVD has no score, explain that the record is awaiting enrichment and that the fix concerns KVM’s AMD SVM instruction handling. That is more useful than assigning an invented severity or forwarding the raw CVE text to an infrastructure team.
This Is Why Nested Virtualization Keeps Getting Scrutiny
Nested virtualization has made hypervisor correctness more complicated. In the old mental model, a guest OS ran on a hypervisor, and the hypervisor kept the guest in a box. In the modern model, a guest may itself run a hypervisor, expose virtual CPU features, and exercise instructions that ordinary applications never touch.That changes testing and threat models. A nested guest can drive code paths that were once obscure, and cloud customers increasingly expect those paths to work. Developers want local labs that mirror production. Security teams want sandboxes inside sandboxes. Platform teams want ephemeral clusters that bring their own virtualization layers.
The KVM community has spent years improving nested SVM and nested VMX behavior because these use cases are real. But the more faithfully a hypervisor exposes virtualization to a guest, the more precisely it must enforce the conditions under which virtualization instructions are valid.
CVE-2026-46082 fits neatly into that story. It is not about a flashy new feature. It is about making the invalid path invalid, because nested virtualization leaves less room for hand-waving around “nobody should execute that anyway.”
Where Windows Guests Fit Into the Risk Model
A Windows guest does not need to be malicious to care about hypervisor correctness. Guest kernels, drivers, anti-cheat systems, security products, emulators, and virtualization-based features all interact with CPU behavior in sophisticated ways. When the host presents a virtual CPU, guest software assumes that CPU behaves according to the architecture.Most Windows workloads will never directly exercise
INVLPGA. But Windows users are often tenants on infrastructure they do not control. If a hosting provider runs Windows VMs on KVM, the security posture of those Windows guests depends partly on the provider’s Linux host patching.For enterprise IT, the lesson is contractual as much as technical. Ask providers how they handle host kernel CVEs. Ask whether AMD KVM nodes are patched through rolling maintenance. Ask how nested virtualization is exposed and constrained. The details matter more than a marketing statement about “enterprise-grade isolation.”
For home lab users, the advice is simpler. If you run AMD-based KVM hosts, install kernel updates from your distribution and reboot into them. If you run Windows guests on that host, do not confuse guest Windows Update with host security maintenance.
The Small KVM Fix That Should Change a Few Patch Calendars
CVE-2026-46082 should not trigger panic, but it should trigger inventory, patch planning, and a quick look at virtualization exposure. The most concrete reading of the public record is that Linux KVM failed to inject#UD for one AMD SVM instruction when SVM was disabled, and the stable fix restores the expected architectural behavior.- Hosts running Linux KVM on AMD processors are the systems most relevant to this CVE.
- The fix belongs on the virtualization host kernel, not inside Windows or Linux guest operating systems.
- The absence of an NVD score at publication time means enrichment was pending, not that the issue was proven harmless.
- Nested virtualization and untrusted guest workloads raise the practical importance of this kind of hypervisor correctness bug.
- Administrators should consume the fix through distribution or platform kernel updates and verify that hosts have rebooted into the patched kernel.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-28T01:12:00-07:00
NVD - CVE-2026-46082
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-28T01:12:00-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: spinics.net
[PATCH V4 2/4] KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 — Linux Kernel
Linux Kernel: [PATCH V4 2/4] KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0
www.spinics.net
- Related coverage: opennet.ru
- Related coverage: patchew.org
- Official source: learn.microsoft.com
