CVE-2026-45987 is a newly published Linux kernel KVM vulnerability, disclosed by kernel.org and listed by NVD on May 27, 2026, involving AMD nested virtualization state handling that can cause an L2 virtual machine to hang after restore or migration. The bug is not a flashy remote-code-execution story, and NVD had not assigned a CVSS score at publication time. But it lands in a part of the stack where small bookkeeping errors can become operationally expensive: live migration, nested hypervisors, CI farms, lab clouds, and virtualization-heavy developer environments.
The short version is this: KVM’s AMD SVM nested virtualization path failed to copy one CPU-written state bit into the cached version of a nested virtual-machine control block after an L2 guest ran. Under one restore ordering, the interrupt shadow could be restored into the wrong layer of the nested stack. That is the sort of defect that looks academic until an apparently healthy virtual CPU stops waking up.
The phrase “Sync interrupt shadow to cached vmcb12 after VMRUN of L2” reads like a commit message that escaped into the CVE database without translation. In this case, that is almost exactly what happened. The CVE description is essentially the upstream kernel fix: after running a nested guest on AMD SVM, KVM synchronizes CPU-written fields from the merged runtime VMCB back into the cached copy of the L1-provided VMCB, but it was missing
That missing field matters because nested virtualization is a hall of mirrors. The physical host, or L0, runs a hypervisor. That hypervisor may host an L1 guest that is itself running a hypervisor. That L1 hypervisor may then run an L2 guest. To make this work, KVM maintains multiple versions of the virtual-machine control block, including a cached
The flaw is not that KVM forgot about interrupts altogether. It is subtler: the CPU can update bit 0 of
That is why the bug is interesting. CVE-2026-45987 is less about a malicious packet or a poisoned file and more about the integrity of virtualization state across time. The machine does the right thing in the moment, then writes down the wrong memory of what happened.
The affected path is KVM’s nested SVM implementation, commonly abbreviated nSVM. SVM is AMD’s hardware virtualization technology, while KVM is the Linux kernel hypervisor facility used by QEMU, libvirt, Proxmox, OpenStack deployments, developer workstations, and countless internal test platforms. Nested SVM is the part that lets an AMD-backed KVM host run a guest hypervisor that runs another guest beneath it.
After an L2 guest exits, KVM has to reconcile state between the hardware-facing control block used to run the nested guest and the virtual control block that the L1 hypervisor believes it owns. That reconciliation is handled by routines such as
The public fix says
This is the kind of bug that sysadmins hate because it is not dramatic enough to be obvious. It does not necessarily announce itself with a clean kernel panic. It can present as a nested guest that simply stops making progress, especially around halt and wakeup behavior.
The CVE description gives the practical consequence: for L1, the misplaced state would “mostly” be benign because it may only delay an interrupt. For L2, however, the vCPU could hang. One example given is a wakeup interrupt delivered before a
That example is worth unpacking. A halted virtual CPU depends on interrupts to wake it. If an interrupt arrives too early, before the guest actually goes to sleep, the guest may then execute
That distinction matters for risk triage. A denial-of-service condition inside nested virtualization may not threaten a laptop user browsing the web, but it can disrupt automated test systems, cloud development environments, nested Kubernetes labs, malware sandboxes, and training platforms. In those environments, “the nested guest hung” is not a cosmetic bug; it is lost time, failed jobs, and sometimes a bad migration window.
The vulnerability is also a reminder that CPU virtualization is not just about isolation. It is about preserving architectural illusions across exits, entries, saves, restores, migrations, and userspace APIs. Break one illusion at the wrong boundary, and the guest can behave as if hardware itself became unreliable.
Kernel CVEs increasingly arrive as a pipeline artifact of upstream fixes. The Linux kernel project assigns CVEs to many resolved bugs, including issues that are highly configuration-specific or require unusual operating conditions. That process improves traceability, but it also means administrators cannot treat every fresh kernel CVE as equal just because it appears in a vulnerability scanner.
CVE-2026-45987 is a good example of why context is everything. If your Linux systems do not use KVM, do not run AMD SVM, and do not enable nested virtualization, the direct exposure is likely minimal. If you operate hosts where nested KVM on AMD is a supported feature, the bug is squarely in your lane.
The likely impact, based on the public description, is availability rather than confidentiality or integrity. There is no public indication in the CVE text that this permits a guest escape, host code execution, cross-VM data theft, or privilege escalation. The concern is that nested L2 vCPUs can hang because restored interrupt-shadow state goes to the wrong place.
That still deserves attention. Availability bugs in infrastructure are often dismissed until they align with automation. A single nested-guest hang in a developer lab is annoying. The same hang in a continuous-integration fleet, cloud validation pipeline, or migration-heavy hosting environment can become a recurring outage pattern.
That points toward workloads involving migration, suspend/resume, checkpointing, snapshot restoration, or virtualization management stacks that reconstruct vCPU state. QEMU is the obvious user of KVM’s ioctls, though the CVE text itself describes the kernel side rather than naming a specific userspace failure. The important operational point is that a nested VM may survive ordinary execution but encounter trouble when its state is serialized and brought back.
The ordering issue is especially frustrating because both orders can seem reasonable to a userspace component. Hypervisors expose state through multiple APIs because the model is complex. If one ordering works and another does not, the kernel is effectively leaking an undocumented coupling into userspace behavior.
The fix removes that coupling by making the cached
That is the quiet beauty of the patch. It does not add a new policy, workaround, or special case for migration. It updates the canonical record so the rest of the machinery can keep assuming the record is true.
This CVE is not a Windows vulnerability. It does not imply that Hyper-V has the same bug, and it does not mean a Windows guest is uniquely at risk. But a Windows L2 guest running inside a nested hypervisor on an affected AMD-backed KVM host could be one of the workloads that experiences a hang.
The affected configuration is narrower than “Linux is vulnerable.” You need Linux KVM, AMD SVM nested virtualization, and a workload path where L2 state is saved or restored in the problematic way. Intel VMX nested virtualization is a different implementation path. Non-nested KVM guests are not the center of this CVE’s description.
That narrowness is good news for patch prioritization but bad news for detection. Highly specific bugs often evade generic monitoring. A sysadmin may see only that a nested lab VM stopped responding after a migration, snapshot restore, or resume operation. Unless the team correlates the timing with kernel versions and nested virtualization, it may be misdiagnosed as a guest OS bug, QEMU oddity, storage pause, or random lab flakiness.
For AMD-heavy environments, especially those running EPYC-based virtualization clusters, the practical question is not whether every guest is exposed. It is whether nested virtualization is enabled and relied upon. Many organizations enable it only for specific pools. Those pools should be mapped.
This is common in the Linux kernel world. A bug is found, patched upstream, backported to supported stable trees, and then later receives a CVE entry. The CVE publication date is therefore not always the same as the date defenders first had access to a fix.
For administrators, the lesson is to track vendor kernels rather than raw upstream commit IDs alone. Red Hat, SUSE, Ubuntu, Debian, Oracle, Proxmox, and other downstreams may ship the fix through their own kernel advisories, package versions, and backport conventions. A downstream kernel may contain the patch without having the same upstream version number that appears in a generic Linux changelog.
That distinction becomes especially important with long-term kernels. The public references include stable-tree activity, and one visible stable review line associates the fix with the 6.12 stable series. But production distributions often carry heavily patched kernels whose version strings do not map cleanly to upstream release numbers. The only reliable answer is the vendor’s patched package metadata or the presence of the specific fix in the kernel source package.
Security teams should resist the scanner-driven habit of demanding an upstream version number and treating everything below it as vulnerable. Kernel backports make that logic brittle. The better question is whether the installed kernel package includes the nSVM interrupt-shadow synchronization fix.
A guest hang can still be painful. Nested virtualization is widely used in places where repeatability is the product. Cloud-init validation, Windows deployment testing, virtualization training, malware detonation labs, Android emulator farms, Kubernetes-in-VM demonstrations, and hypervisor development all lean on nested execution. The affected bug is exactly the sort of edge condition that can turn rare timing into a reproducible CI failure once the right migration or restore path is involved.
The risk is higher where L2 guests are expected to survive lifecycle operations. If nested VMs are disposable and never migrated, the practical exposure may be lower. If nested VMs are checkpointed, paused, resumed, snapshotted, or moved across hosts, the state-restoration angle becomes more relevant.
The bug also has a subtle support cost. When a nested guest hangs, the user often blames the innermost operating system. A Windows L2 guest may look frozen, a Linux L2 guest may stop responding to interrupts, and the L1 hypervisor may appear confused. But the root cause can be L0 KVM restoring state incorrectly beneath both of them.
That is why infrastructure teams should document nested virtualization as a dependency. If you cannot quickly answer which hosts run nested SVM workloads, you cannot quickly answer whether this CVE matters.
Small fixes like this are easy to underestimate. They usually change little code, but they encode a lot of architectural knowledge. The developer has to know which structure is authoritative, which bits the CPU writes, which paths save nested state, and which userspace API orderings can expose inconsistency.
That is also why administrators should be cautious about ad hoc mitigation advice. Disabling nested virtualization will avoid the affected path, but it may break legitimate workloads. Avoiding live migration or restore operations for nested guests may reduce exposure, but it is a process workaround, not a fix. Updating the host kernel is the clean answer.
In environments with strict change windows, the interim approach is to identify AMD KVM hosts with nested virtualization enabled, then prioritize those that run persistent L2 guests or perform nested VM migration/restoration. That is a more rational response than emergency-patching every Linux system with no regard for whether KVM or nSVM is in use.
For home-lab users, the advice is simpler. If you run Proxmox, libvirt, or raw QEMU/KVM on AMD hardware and you experiment with nested hypervisors, keep an eye on your distribution’s kernel updates. If you have seen L2 guests hang after snapshots or resume, this CVE is worth checking against your host kernel history.
Good triage starts with configuration. A Linux box that never loads KVM is not in the same risk category as a virtualization host. A KVM host that never enables nested virtualization is not in the same category as one that sells nested cloud instances or runs hypervisor CI. An Intel-based host is not exercising the AMD nSVM path described by the fix.
The problem is that asset inventories often stop at operating system and package version. They know a server runs Linux. They may know it runs QEMU. They may not know whether nested virtualization is enabled, whether the CPU vendor is AMD, whether L2 guests are used, or whether live migration includes nested state. CVE-2026-45987 punishes that lack of detail.
Security teams should use this bug as an excuse to improve their virtualization inventory. That does not require a heroic project. At minimum, teams should distinguish general-purpose Linux servers from KVM hosts, KVM hosts from nested-capable hosts, and nested-capable hosts from hosts that actually run nested workloads.
The payoff extends beyond this one CVE. The next KVM issue may affect interrupt injection, APIC emulation, VMX state, SVM intercepts, or device assignment. Knowing the shape of the virtualization estate will make every future advisory less chaotic.
This matters in mixed labs. A common pattern is an AMD Linux host running KVM, an L1 Windows Server or Linux hypervisor, and then an L2 Windows guest used for testing domain joins, update rings, deployment tooling, or endpoint security products. If that L2 guest hangs after restore, the debugging trail can lead administrators into the wrong layer.
Nested virtualization makes blame assignment hard because every layer has a plausible story. The L2 guest thinks it is on real hardware. The L1 hypervisor thinks it controls the guest. The L0 host is quietly emulating the conditions that let both beliefs hold. CVE-2026-45987 is a failure in that quiet emulation.
Windows administrators who rely on third-party hosting or internal Linux virtualization should ask provider teams about host kernel remediation, not guest patches. If the host is affected, updating the Windows guest will not correct KVM’s cached nested-state handling. Conversely, if the host kernel is fixed, no special Windows-side action should be needed for this CVE alone.
That is the operational discipline nested environments demand. Troubleshoot from the bottom up when the symptom appears after migration, snapshot, suspend, or resume. The bug may be underneath the OS that appears frozen.
The more interesting response is cultural. Nested VM hangs are often treated as lab weirdness, especially when they occur in developer or test infrastructure. This CVE shows why that attitude can be expensive. A hang that appears random may be the visible edge of a precise kernel state bug.
Kernel virtualization is mature, but mature does not mean simple. The save/restore path for nested vCPUs is one of the places where the abstraction becomes thinnest. When those paths are wrong, they can damage confidence in the whole stack even if the underlying fix is only a few lines.
The best infrastructure teams will use this as a forcing function. They will identify nested workloads, confirm patched kernels, and add version context to any lingering L2 freeze reports. The worst teams will wait until a scanner assigns a scary number and then scramble without knowing whether the vulnerable path exists on their hosts.
The short version is this: KVM’s AMD SVM nested virtualization path failed to copy one CPU-written state bit into the cached version of a nested virtual-machine control block after an L2 guest ran. Under one restore ordering, the interrupt shadow could be restored into the wrong layer of the nested stack. That is the sort of defect that looks academic until an apparently healthy virtual CPU stops waking up.
A Kernel Bug With a Boring Name Hits a Very Specific Nerve
The phrase “Sync interrupt shadow to cached vmcb12 after VMRUN of L2” reads like a commit message that escaped into the CVE database without translation. In this case, that is almost exactly what happened. The CVE description is essentially the upstream kernel fix: after running a nested guest on AMD SVM, KVM synchronizes CPU-written fields from the merged runtime VMCB back into the cached copy of the L1-provided VMCB, but it was missing int_state.That missing field matters because nested virtualization is a hall of mirrors. The physical host, or L0, runs a hypervisor. That hypervisor may host an L1 guest that is itself running a hypervisor. That L1 hypervisor may then run an L2 guest. To make this work, KVM maintains multiple versions of the virtual-machine control block, including a cached
vmcb12 that represents what the L1 hypervisor thinks it gave the hardware.The flaw is not that KVM forgot about interrupts altogether. It is subtler: the CPU can update bit 0 of
int_state, the SVM interrupt-shadow bit, while an L2 guest is running. KVM synchronized other CPU-written controls back into the cached nested state, but not this one. When userspace later saved or restored nested state, the cached copy could lie by omission.That is why the bug is interesting. CVE-2026-45987 is less about a malicious packet or a poisoned file and more about the integrity of virtualization state across time. The machine does the right thing in the moment, then writes down the wrong memory of what happened.
The Vulnerability Lives in the Gap Between Running and Remembering
Virtualization bugs often divide into two broad categories. Some are escape bugs, where the guest breaks out of its box. Others are correctness bugs, where the hypervisor mishandles guest state and produces crashes, corruption, hangs, or migration failures. CVE-2026-45987 belongs squarely in the second category based on the public description.The affected path is KVM’s nested SVM implementation, commonly abbreviated nSVM. SVM is AMD’s hardware virtualization technology, while KVM is the Linux kernel hypervisor facility used by QEMU, libvirt, Proxmox, OpenStack deployments, developer workstations, and countless internal test platforms. Nested SVM is the part that lets an AMD-backed KVM host run a guest hypervisor that runs another guest beneath it.
After an L2 guest exits, KVM has to reconcile state between the hardware-facing control block used to run the nested guest and the virtual control block that the L1 hypervisor believes it owns. That reconciliation is handled by routines such as
nested_sync_control_from_vmcb02(). The cached vmcb12 is treated as authoritative for some control fields and is also used as payload during nested-state save and restore.The public fix says
int_state should have been included in that synchronization. Without it, the restore path becomes order-dependent. If userspace calls KVM_SET_NESTED_STATE before KVM_SET_VCPU_EVENTS, the interrupt shadow can be restored correctly into the L2 execution context. If the calls arrive in the opposite order, the interrupt shadow can land in vmcb01, the L1 context, rather than vmcb02, the L2 context.This is the kind of bug that sysadmins hate because it is not dramatic enough to be obvious. It does not necessarily announce itself with a clean kernel panic. It can present as a nested guest that simply stops making progress, especially around halt and wakeup behavior.
The Interrupt Shadow Is Small, but the Failure Mode Is Not
An interrupt shadow is a temporary state in which interrupts are blocked or delayed after certain instructions or events. It is one of those CPU details that most users never need to know exists, but hypervisors have to model it faithfully. If a virtual CPU is supposed to be in an interrupt shadow and the hypervisor loses that fact, the timing of interrupt delivery can change.The CVE description gives the practical consequence: for L1, the misplaced state would “mostly” be benign because it may only delay an interrupt. For L2, however, the vCPU could hang. One example given is a wakeup interrupt delivered before a
HLT instruction that should have been protected by the interrupt shadow.That example is worth unpacking. A halted virtual CPU depends on interrupts to wake it. If an interrupt arrives too early, before the guest actually goes to sleep, the guest may then execute
HLT and wait for an interrupt that already came and went. From the outside, this can look like a frozen nested guest rather than a security event.That distinction matters for risk triage. A denial-of-service condition inside nested virtualization may not threaten a laptop user browsing the web, but it can disrupt automated test systems, cloud development environments, nested Kubernetes labs, malware sandboxes, and training platforms. In those environments, “the nested guest hung” is not a cosmetic bug; it is lost time, failed jobs, and sometimes a bad migration window.
The vulnerability is also a reminder that CPU virtualization is not just about isolation. It is about preserving architectural illusions across exits, entries, saves, restores, migrations, and userspace APIs. Break one illusion at the wrong boundary, and the guest can behave as if hardware itself became unreliable.
NVD’s Empty Scorecard Should Not Be Mistaken for an Empty Risk
At the time the CVE appeared, NVD had marked the record as awaiting enrichment and had not supplied CVSS 4.0, CVSS 3.x, or CVSS 2.0 scoring. That absence is not a verdict of harmlessness. It means the database has not yet attached a formal vector and severity calculation.Kernel CVEs increasingly arrive as a pipeline artifact of upstream fixes. The Linux kernel project assigns CVEs to many resolved bugs, including issues that are highly configuration-specific or require unusual operating conditions. That process improves traceability, but it also means administrators cannot treat every fresh kernel CVE as equal just because it appears in a vulnerability scanner.
CVE-2026-45987 is a good example of why context is everything. If your Linux systems do not use KVM, do not run AMD SVM, and do not enable nested virtualization, the direct exposure is likely minimal. If you operate hosts where nested KVM on AMD is a supported feature, the bug is squarely in your lane.
The likely impact, based on the public description, is availability rather than confidentiality or integrity. There is no public indication in the CVE text that this permits a guest escape, host code execution, cross-VM data theft, or privilege escalation. The concern is that nested L2 vCPUs can hang because restored interrupt-shadow state goes to the wrong place.
That still deserves attention. Availability bugs in infrastructure are often dismissed until they align with automation. A single nested-guest hang in a developer lab is annoying. The same hang in a continuous-integration fleet, cloud validation pipeline, or migration-heavy hosting environment can become a recurring outage pattern.
The Restore Ordering Detail Points Straight at Migration and Userspace
The most revealing part of the CVE text is not the missing bit. It is the restore-order dependency betweenKVM_SET_NESTED_STATE and KVM_SET_VCPU_EVENTS. Those are KVM userspace API calls used to reconstruct vCPU and nested virtualization state. In practice, that means the bug is not merely about running an L2 guest; it is about saving and restoring it accurately.That points toward workloads involving migration, suspend/resume, checkpointing, snapshot restoration, or virtualization management stacks that reconstruct vCPU state. QEMU is the obvious user of KVM’s ioctls, though the CVE text itself describes the kernel side rather than naming a specific userspace failure. The important operational point is that a nested VM may survive ordinary execution but encounter trouble when its state is serialized and brought back.
The ordering issue is especially frustrating because both orders can seem reasonable to a userspace component. Hypervisors expose state through multiple APIs because the model is complex. If one ordering works and another does not, the kernel is effectively leaking an undocumented coupling into userspace behavior.
The fix removes that coupling by making the cached
vmcb12 carry the correct interrupt-shadow state. Once the cached nested state is accurate, KVM_SET_NESTED_STATE restores the right value into the L2 context, and a later KVM_SET_VCPU_EVENTS simply writes the same value again. The system becomes less dependent on choreography.That is the quiet beauty of the patch. It does not add a new policy, workaround, or special case for migration. It updates the canonical record so the rest of the machinery can keep assuming the record is true.
AMD Nested Virtualization Is the Narrow Doorway, Not the Whole House
WindowsForum readers who mostly live on Windows hosts may wonder why a Linux KVM CVE deserves attention here. The answer is that modern Windows infrastructure often sits beside Linux virtualization, not apart from it. Windows Server evaluation labs, Active Directory test forests, Windows 11 deployment rings, Intune simulations, and nested Hyper-V experiments are frequently built on Linux KVM hosts, especially in home labs and budget-conscious IT shops.This CVE is not a Windows vulnerability. It does not imply that Hyper-V has the same bug, and it does not mean a Windows guest is uniquely at risk. But a Windows L2 guest running inside a nested hypervisor on an affected AMD-backed KVM host could be one of the workloads that experiences a hang.
The affected configuration is narrower than “Linux is vulnerable.” You need Linux KVM, AMD SVM nested virtualization, and a workload path where L2 state is saved or restored in the problematic way. Intel VMX nested virtualization is a different implementation path. Non-nested KVM guests are not the center of this CVE’s description.
That narrowness is good news for patch prioritization but bad news for detection. Highly specific bugs often evade generic monitoring. A sysadmin may see only that a nested lab VM stopped responding after a migration, snapshot restore, or resume operation. Unless the team correlates the timing with kernel versions and nested virtualization, it may be misdiagnosed as a guest OS bug, QEMU oddity, storage pause, or random lab flakiness.
For AMD-heavy environments, especially those running EPYC-based virtualization clusters, the practical question is not whether every guest is exposed. It is whether nested virtualization is enabled and relied upon. Many organizations enable it only for specific pools. Those pools should be mapped.
The Patch Trail Shows a Kernel Maintenance Story, Not a Panic
The public references attached to the CVE point to Linux stable commits and stable review activity. The patch series was circulating on kernel mailing lists earlier in 2026, with stable backporting visible before the CVE record appeared in NVD. That timeline matters because it suggests the fix was part of the normal kernel maintenance flow before many scanners started flagging the CVE identifier.This is common in the Linux kernel world. A bug is found, patched upstream, backported to supported stable trees, and then later receives a CVE entry. The CVE publication date is therefore not always the same as the date defenders first had access to a fix.
For administrators, the lesson is to track vendor kernels rather than raw upstream commit IDs alone. Red Hat, SUSE, Ubuntu, Debian, Oracle, Proxmox, and other downstreams may ship the fix through their own kernel advisories, package versions, and backport conventions. A downstream kernel may contain the patch without having the same upstream version number that appears in a generic Linux changelog.
That distinction becomes especially important with long-term kernels. The public references include stable-tree activity, and one visible stable review line associates the fix with the 6.12 stable series. But production distributions often carry heavily patched kernels whose version strings do not map cleanly to upstream release numbers. The only reliable answer is the vendor’s patched package metadata or the presence of the specific fix in the kernel source package.
Security teams should resist the scanner-driven habit of demanding an upstream version number and treating everything below it as vulnerable. Kernel backports make that logic brittle. The better question is whether the installed kernel package includes the nSVM interrupt-shadow synchronization fix.
The Real-World Blast Radius Is Availability in Nested Stacks
The public vulnerability text describes a hang, not a compromise. That matters. In a year where kernel CVEs often get flattened into the same red-alert dashboard, CVE-2026-45987 is a reminder that impact type is as important as severity.A guest hang can still be painful. Nested virtualization is widely used in places where repeatability is the product. Cloud-init validation, Windows deployment testing, virtualization training, malware detonation labs, Android emulator farms, Kubernetes-in-VM demonstrations, and hypervisor development all lean on nested execution. The affected bug is exactly the sort of edge condition that can turn rare timing into a reproducible CI failure once the right migration or restore path is involved.
The risk is higher where L2 guests are expected to survive lifecycle operations. If nested VMs are disposable and never migrated, the practical exposure may be lower. If nested VMs are checkpointed, paused, resumed, snapshotted, or moved across hosts, the state-restoration angle becomes more relevant.
The bug also has a subtle support cost. When a nested guest hangs, the user often blames the innermost operating system. A Windows L2 guest may look frozen, a Linux L2 guest may stop responding to interrupts, and the L1 hypervisor may appear confused. But the root cause can be L0 KVM restoring state incorrectly beneath both of them.
That is why infrastructure teams should document nested virtualization as a dependency. If you cannot quickly answer which hosts run nested SVM workloads, you cannot quickly answer whether this CVE matters.
The Fix Is Small Because the Model Is Large
The remediation concept is straightforward: synchronizeint_state to the cached vmcb12 inside nested_sync_control_from_vmcb02(). In plain English, when the physical CPU updates the interrupt-shadow state while running the nested guest, KVM must copy that updated state back into the cached nested-control structure that future save and restore operations will trust.Small fixes like this are easy to underestimate. They usually change little code, but they encode a lot of architectural knowledge. The developer has to know which structure is authoritative, which bits the CPU writes, which paths save nested state, and which userspace API orderings can expose inconsistency.
That is also why administrators should be cautious about ad hoc mitigation advice. Disabling nested virtualization will avoid the affected path, but it may break legitimate workloads. Avoiding live migration or restore operations for nested guests may reduce exposure, but it is a process workaround, not a fix. Updating the host kernel is the clean answer.
In environments with strict change windows, the interim approach is to identify AMD KVM hosts with nested virtualization enabled, then prioritize those that run persistent L2 guests or perform nested VM migration/restoration. That is a more rational response than emergency-patching every Linux system with no regard for whether KVM or nSVM is in use.
For home-lab users, the advice is simpler. If you run Proxmox, libvirt, or raw QEMU/KVM on AMD hardware and you experiment with nested hypervisors, keep an eye on your distribution’s kernel updates. If you have seen L2 guests hang after snapshots or resume, this CVE is worth checking against your host kernel history.
Scanner Noise Will Miss the Configuration That Matters
The next phase of this CVE’s life will be predictable. Vulnerability scanners will ingest the NVD record. Dashboards will light up. Some reports will say “Linux kernel vulnerability” without mentioning AMD nested SVM. Busy teams will ask whether they are exposed, and the answer will not be in the CVE headline.Good triage starts with configuration. A Linux box that never loads KVM is not in the same risk category as a virtualization host. A KVM host that never enables nested virtualization is not in the same category as one that sells nested cloud instances or runs hypervisor CI. An Intel-based host is not exercising the AMD nSVM path described by the fix.
The problem is that asset inventories often stop at operating system and package version. They know a server runs Linux. They may know it runs QEMU. They may not know whether nested virtualization is enabled, whether the CPU vendor is AMD, whether L2 guests are used, or whether live migration includes nested state. CVE-2026-45987 punishes that lack of detail.
Security teams should use this bug as an excuse to improve their virtualization inventory. That does not require a heroic project. At minimum, teams should distinguish general-purpose Linux servers from KVM hosts, KVM hosts from nested-capable hosts, and nested-capable hosts from hosts that actually run nested workloads.
The payoff extends beyond this one CVE. The next KVM issue may affect interrupt injection, APIC emulation, VMX state, SVM intercepts, or device assignment. Knowing the shape of the virtualization estate will make every future advisory less chaotic.
The Windows Angle Is Infrastructure, Not Guest Blame
For Windows professionals, the most important framing is that CVE-2026-45987 lives below the guest OS. A Windows Server or Windows 11 VM running as L2 may be the visible victim, but it is not the source of the bug. Reinstalling the guest, changing Windows power settings, or blaming Hyper-V inside the guest may miss the host-side state-restoration defect.This matters in mixed labs. A common pattern is an AMD Linux host running KVM, an L1 Windows Server or Linux hypervisor, and then an L2 Windows guest used for testing domain joins, update rings, deployment tooling, or endpoint security products. If that L2 guest hangs after restore, the debugging trail can lead administrators into the wrong layer.
Nested virtualization makes blame assignment hard because every layer has a plausible story. The L2 guest thinks it is on real hardware. The L1 hypervisor thinks it controls the guest. The L0 host is quietly emulating the conditions that let both beliefs hold. CVE-2026-45987 is a failure in that quiet emulation.
Windows administrators who rely on third-party hosting or internal Linux virtualization should ask provider teams about host kernel remediation, not guest patches. If the host is affected, updating the Windows guest will not correct KVM’s cached nested-state handling. Conversely, if the host kernel is fixed, no special Windows-side action should be needed for this CVE alone.
That is the operational discipline nested environments demand. Troubleshoot from the bottom up when the symptom appears after migration, snapshot, suspend, or resume. The bug may be underneath the OS that appears frozen.
The Sensible Response Is Patch, Prioritize, and Stop Treating Nested VM Hangs as Weather
The concrete response to CVE-2026-45987 is not complicated, but it should be deliberate. Organizations should check whether they operate AMD-based Linux KVM hosts with nested virtualization enabled and then follow their Linux vendor’s kernel update guidance. Environments that do not use nested SVM should still patch on normal cadence, but they do not need to manufacture panic from an unscored NVD entry.The more interesting response is cultural. Nested VM hangs are often treated as lab weirdness, especially when they occur in developer or test infrastructure. This CVE shows why that attitude can be expensive. A hang that appears random may be the visible edge of a precise kernel state bug.
Kernel virtualization is mature, but mature does not mean simple. The save/restore path for nested vCPUs is one of the places where the abstraction becomes thinnest. When those paths are wrong, they can damage confidence in the whole stack even if the underlying fix is only a few lines.
The best infrastructure teams will use this as a forcing function. They will identify nested workloads, confirm patched kernels, and add version context to any lingering L2 freeze reports. The worst teams will wait until a scanner assigns a scary number and then scramble without knowing whether the vulnerable path exists on their hosts.
The Patch Notes Tell IT Exactly Where to Look
CVE-2026-45987 is specific enough that its practical takeaways are unusually clear. The bug is not a generalized Linux meltdown; it is a nested AMD KVM state synchronization problem with an availability-shaped impact.- Systems most likely to care are AMD-based Linux KVM hosts that run nested virtualization with L2 guests.
- The public description points to possible L2 vCPU hangs, especially around restored interrupt-shadow state after save, restore, migration, or similar lifecycle operations.
- NVD had not assigned a CVSS score when the record was published on May 27, 2026, so teams should not wait for scoring to decide whether their configuration is relevant.
- Windows guests can be affected as workloads if they run inside the nested stack, but the corrective action belongs on the Linux KVM host.
- The durable fix is a host kernel update containing the nSVM
int_statesynchronization patch, preferably from the organization’s normal Linux distribution or platform vendor. - Asset inventories that distinguish ordinary Linux servers from AMD nested-KVM hosts will make this and future virtualization CVEs much easier to triage.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-28T01:10:46-07:00
NVD - CVE-2026-45987
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-28T01:10:46-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: spinics.net
[PATCH v2 2/5] KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2 — Linux Kernel
Linux Kernel: [PATCH v2 2/5] KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2
www.spinics.net
- Related coverage: opennet.ru
- Related coverage: patchew.org
