CVE-2026-46014 is a Linux kernel KVM vulnerability published by NVD on May 27, 2026, covering broken save-and-restore handling for Last Branch Record model-specific registers in KVM’s AMD SVM virtualization path, with related Intel VMX bookkeeping also corrected. The bug is not the kind of flaw that lends itself to a splashy exploit demo, and NVD has not yet assigned a CVSS score. But for virtualization operators, kernel maintainers, and anyone running nested VM stacks, it is a reminder that state-management bugs in hypervisors can be security-relevant even when they look like dry plumbing. The story here is not panic; it is the slow collision between modern CPU introspection features and the promise that a virtual machine can be frozen, moved, resumed, and trusted.
The affected code lives in KVM, the Linux kernel’s built-in hypervisor, specifically around SVM, AMD’s virtualization architecture. The vulnerable behavior concerns Last Branch Record, or LBR, registers and
That sounds niche because it is niche. Most administrators do not spend their day thinking about LBRs, VMCBs, or whether
CVE-2026-46014 is therefore best understood as a contract bug. KVM did not properly enumerate the LBR-related MSRs for save and restore, and userspace could not set the LBR MSRs through the ordinary
That phrase will travel farther than the vulnerability itself. It does not necessarily mean every Linux host is in immediate danger, nor does it mean a guest can trivially break out of a VM. It means one slice of architectural CPU state was not being preserved the way the virtualization stack needed it to be preserved. In hypervisor code, that is enough to justify a CVE.
That last detail is the one that makes this more than a bookkeeping cleanup. Nested virtualization complicates the otherwise tidy distinction between host and guest. In a nested setup, an L0 host runs an L1 hypervisor, which in turn runs an L2 guest. The state that must be preserved is no longer just “the VM’s state” in a simple sense; it is state that may belong to a guest acting as a hypervisor, with another guest beneath it.
KVM’s SVM path uses VMCB structures to hold virtualization state. When nested execution is involved, KVM has to juggle the state the real host sees, the state the L1 hypervisor believes it owns, and the state required to run the L2 guest correctly. Missing LBR copying in
That is exactly the class of bug that tends to be underwhelming in a scanner dashboard and important in real infrastructure. It does not scream ransomware. It whispers “migration correctness,” “debugging integrity,” “nested workload isolation,” and “guest-visible architectural fidelity.”
Who gets to see branch history? Which guest’s branch history is currently in the hardware? When the hypervisor switches between guests, which records are saved, restored, masked, or ignored? These questions matter because CPU state is not limited to general-purpose registers and memory pages. Modern processors carry a long tail of performance, debug, security, and speculation-related machinery.
Virtualization has spent years learning this lesson the hard way. Features that began as performance conveniences became isolation concerns once cloud computing made hostile multi-tenancy ordinary. Debug registers, performance counters, branch tracing, speculative-execution controls, and extended CPU capabilities all have to be virtualized carefully because they sit close to the boundary between observation and interference.
CVE-2026-46014 is not being presented as a speculative-execution catastrophe. There is no public CVSS vector from NVD at the time of publication, and the NVD record is still awaiting enrichment. But the affected registers exist in the category of CPU features where “just don’t save that” is not a neutral design choice. If a guest believes it has LBR virtualization, the hypervisor must either provide it correctly or hide it cleanly.
That does not make this an identical Intel and AMD bug. The LBR virtualization mechanics differ, and the main nested-SVM correction is plainly aimed at AMD’s path. Still, the Intel note is important because it shows how cross-vendor x86 support can accumulate mismatches in shared infrastructure. KVM’s x86 layer has common machinery, but vendor-specific virtualization backends still have to express what state exists, what can be exposed, and what userspace is allowed to manipulate.
The patch also acknowledges that over-reporting certain Intel
For administrators, the Intel angle changes the risk conversation only slightly. This CVE should still be tracked primarily as a KVM virtualization-state bug, with the highest relevance for hosts using KVM features that exercise debug, branch-record, migration, snapshot, or nested virtualization paths. It is not a Windows desktop bug, but Windows guests running on affected Linux/KVM hosts are part of the blast radius in the ordinary operational sense: the guest OS does not have to be Linux for the hypervisor’s state handling to matter.
That still matters. Cloud providers, CI farms, lab environments, security sandboxes, and developer workstations increasingly rely on nested virtualization. A Windows-on-Linux test rig using KVM, a Kubernetes node running VM-based isolation, or a virtualization cluster that supports live migration can all depend on precise state transfer in ways that only become visible when something breaks.
The most obvious symptom class would be correctness failure rather than compromise: lost or incorrect branch-record state after migration, snapshot restore, or nested guest transitions. But security boundaries are built out of correctness. If userspace VMMs cannot enumerate and restore the CPU state they are responsible for, they may make decisions based on incomplete information.
That is why kernel CVEs often frustrate people outside the kernel world. They do not always map cleanly to “attacker does X, gains Y.” Sometimes the vulnerability is that a subsystem violated the invariant other layers rely on. In virtualization, violated invariants are the beginning of many worse stories.
The Windows angle is especially obvious for nested virtualization. Developers run Hyper-V, WSL, Android emulators, container stacks, and test VMs in configurations that may pass through multiple virtualization layers. Enterprises run Windows guests on non-Microsoft hypervisors for cost, density, or platform reasons. Security researchers routinely nest Windows targets inside Linux/KVM environments.
If the host hypervisor mishandles CPU debug or branch-history state, the Windows guest may not “know” it is affected. But the reliability of VM pause, resume, migration, snapshotting, debugging, and nested execution is still part of the Windows workload’s trust model. The guest does not need to carry the vulnerable code to suffer from a host-level virtualization defect.
This is also why patch triage should not stop at OS branding. A Windows estate may have no vulnerable Linux endpoints and still depend on vulnerable Linux hypervisors. Conversely, a Linux desktop user who never enables KVM, never runs nested virtualization, and never exposes LBR virtualization may have little practical exposure beyond the ordinary need to stay current.
CVE-2026-46014 fits that pattern. The record was received from kernel.org, the NVD page was published and last modified on May 27, 2026, and enrichment had not yet added scoring or weakness classification. The public references point to stable kernel commits rather than a vendor advisory with polished impact language.
That is not a defect in the process. It is a transparency tradeoff. Defenders get earlier visibility into kernel fixes that may have security implications, but they also get less packaging. Instead of a neat vendor severity badge, they get subsystem names, register names, commit hashes, and enough ambiguity to require actual engineering judgment.
For IT shops, this means vulnerability management must become more context-aware. A CVE affecting KVM’s SVM path should not be treated the same way on a desktop with no virtualization features enabled, a cloud host running untrusted tenants, and a lab box doing nested hypervisor testing. The scanner result is the start of the triage, not the end.
Priority should be highest for hosts that run untrusted guests, support nested virtualization, rely on live migration or suspend/resume, or expose advanced CPU profiling/debug features to guests. Those are the environments where broken save-and-restore behavior is most likely to cross from theoretical to operationally meaningful. If you run single-purpose trusted VMs with no nested virtualization and a conservative CPU feature mask, the urgency is lower, but the fix still belongs in the normal kernel update train.
The one operational trap is reboot discipline. Kernel fixes do not protect a running host until the fixed kernel is booted, unless a live-patching vendor explicitly covers the affected code path. Many organizations “install” kernel updates but defer reboots for weeks. For hypervisor hosts, that can create a false sense of closure in vulnerability dashboards.
There is also a migration wrinkle. If your fleet mixes fixed and unfixed KVM hosts, VM movement can become the place where state bugs show up. That does not mean every cluster must be drained immediately, but it does argue for patching virtualization pools coherently rather than sprinkling updates across hosts at random.
Strip away the jargon and the lesson is simple: a hypervisor must faithfully virtualize the CPU features it exposes. If a feature is visible to the guest and relevant to execution, the hypervisor must know how to preserve it across the lifecycle of a VM. Anything else is a trap for management software, nested hypervisors, and forensic assumptions.
That is why the fix allows userspace writes to LBR MSRs only when LBR virtualization is enabled. KVM is not simply opening a write-anything path to read-only hardware registers. It is giving trusted userspace VMMs a way to restore guest-visible virtual state under the conditions where that state is supposed to exist.
That distinction matters. Hypervisor userspace is not an arbitrary app in this model; it is part of the virtualization stack. QEMU and similar VMM components rely on kernel interfaces to snapshot and rebuild the guest CPU model. If the kernel does not expose the relevant pieces, userspace cannot do the right thing even if it wants to.
The visible commit history also tells a useful story. The patch went through multiple revisions in the kernel mailing-list process, with discussion around reserved bits, userspace behavior, and the correct guard conditions for LBR virtualization. That is normal kernel work, but it is also evidence that this was not a drive-by one-line fix. The maintainers were refining the boundary between guest state, userspace restoration, and hardware semantics.
For enterprise teams, the right inventory question is not “Do we have CVE-2026-46014?” in isolation. It is “Which systems run KVM hosts, which of those expose nested virtualization or advanced CPU features, and which of those host workloads we do not fully trust?” The answer determines whether this is a routine maintenance item or a near-term hypervisor patch.
For Windows-heavy teams, the question is slightly different: “Where do our Windows workloads sit on Linux/KVM infrastructure we do not patch directly?” That may mean public cloud, private cloud, managed hosting, VDI, or lab environments. If someone else owns the host, the action is to check provider advisories and maintenance windows, not to patch the Windows guest.
The concrete takeaways are narrow but useful:
A Small Register Bug Exposes a Big Virtualization Assumption
The affected code lives in KVM, the Linux kernel’s built-in hypervisor, specifically around SVM, AMD’s virtualization architecture. The vulnerable behavior concerns Last Branch Record, or LBR, registers and MSR_IA32_DEBUGCTLMSR, which are part of the CPU’s machinery for recording recent control-flow history and enabling certain debugging or profiling behavior.That sounds niche because it is niche. Most administrators do not spend their day thinking about LBRs, VMCBs, or whether
KVM_GET_MSR_INDEX_LIST exposes the right model-specific registers to userspace. But the entire point of a hypervisor is that the guest’s CPU state is not merely a pile of values; it is a contract. If the hypervisor says a VM can be saved, restored, migrated, nested, or debugged, the CPU state that matters must go along for the ride.CVE-2026-46014 is therefore best understood as a contract bug. KVM did not properly enumerate the LBR-related MSRs for save and restore, and userspace could not set the LBR MSRs through the ordinary
KVM_SET_MSRS path. The upstream description is blunt: save and restore was “completely broken” for this portion of state.That phrase will travel farther than the vulnerability itself. It does not necessarily mean every Linux host is in immediate danger, nor does it mean a guest can trivially break out of a VM. It means one slice of architectural CPU state was not being preserved the way the virtualization stack needed it to be preserved. In hypervisor code, that is enough to justify a CVE.
The Kernel Fix Is About State, Not Spectacle
The patch does three practical things. It adds the missing MSRs to KVM’s base list of registers to save, it permits userspace writes to LBR MSRs when LBR virtualization is enabled, and it ensures nested SVM correctly copies LBR state from the captured VMCB01 save area while an L2 guest is running.That last detail is the one that makes this more than a bookkeeping cleanup. Nested virtualization complicates the otherwise tidy distinction between host and guest. In a nested setup, an L0 host runs an L1 hypervisor, which in turn runs an L2 guest. The state that must be preserved is no longer just “the VM’s state” in a simple sense; it is state that may belong to a guest acting as a hypervisor, with another guest beneath it.
KVM’s SVM path uses VMCB structures to hold virtualization state. When nested execution is involved, KVM has to juggle the state the real host sees, the state the L1 hypervisor believes it owns, and the state required to run the L2 guest correctly. Missing LBR copying in
svm_copy_vmrun_state() meant L1’s branch-record state could be mishandled while L2 was active.That is exactly the class of bug that tends to be underwhelming in a scanner dashboard and important in real infrastructure. It does not scream ransomware. It whispers “migration correctness,” “debugging integrity,” “nested workload isolation,” and “guest-visible architectural fidelity.”
LBR Is a Performance Feature Until It Becomes a Boundary Feature
Last Branch Record support exists so software can inspect recent branch behavior. Profilers, debuggers, performance tools, and security mechanisms can use this kind of CPU state to understand control flow without instrumenting every instruction. On bare metal, that is already delicate. In a VM, it becomes a question of ownership.Who gets to see branch history? Which guest’s branch history is currently in the hardware? When the hypervisor switches between guests, which records are saved, restored, masked, or ignored? These questions matter because CPU state is not limited to general-purpose registers and memory pages. Modern processors carry a long tail of performance, debug, security, and speculation-related machinery.
Virtualization has spent years learning this lesson the hard way. Features that began as performance conveniences became isolation concerns once cloud computing made hostile multi-tenancy ordinary. Debug registers, performance counters, branch tracing, speculative-execution controls, and extended CPU capabilities all have to be virtualized carefully because they sit close to the boundary between observation and interference.
CVE-2026-46014 is not being presented as a speculative-execution catastrophe. There is no public CVSS vector from NVD at the time of publication, and the NVD record is still awaiting enrichment. But the affected registers exist in the category of CPU features where “just don’t save that” is not a neutral design choice. If a guest believes it has LBR virtualization, the hypervisor must either provide it correctly or hide it cleanly.
The AMD Path Is the Headline, but Intel Gets a Footnote That Matters
The vulnerability description centers on KVM’s SVM code, which means AMD virtualization. The fix, however, also notes a VMX-side correction:MSR_IA32_DEBUGCTLMSR was not being reported as an MSR to save and restore on Intel either.That does not make this an identical Intel and AMD bug. The LBR virtualization mechanics differ, and the main nested-SVM correction is plainly aimed at AMD’s path. Still, the Intel note is important because it shows how cross-vendor x86 support can accumulate mismatches in shared infrastructure. KVM’s x86 layer has common machinery, but vendor-specific virtualization backends still have to express what state exists, what can be exposed, and what userspace is allowed to manipulate.
The patch also acknowledges that over-reporting certain Intel
MSR_IA32_LAST* registers is acceptable because KVM already has logic to absorb unsupported accesses in a safe way. That is an unglamorous but valuable pattern: better to advertise a consistent save-and-restore interface and let unsupported operations collapse into no-ops than to silently omit state a VM manager may need.For administrators, the Intel angle changes the risk conversation only slightly. This CVE should still be tracked primarily as a KVM virtualization-state bug, with the highest relevance for hosts using KVM features that exercise debug, branch-record, migration, snapshot, or nested virtualization paths. It is not a Windows desktop bug, but Windows guests running on affected Linux/KVM hosts are part of the blast radius in the ordinary operational sense: the guest OS does not have to be Linux for the hypervisor’s state handling to matter.
The Real-World Risk Is Operational Before It Is Exploit-Driven
The absence of an NVD score is not unusual for a newly published kernel CVE. It does mean defenders should avoid inventing severity where the public record has not yet put numbers. There is no need to pretend this is a remote unauthenticated code execution issue. Based on the available description, the most credible concerns are incorrect VM save/restore behavior, nested virtualization misbehavior, and exposure to userspace/hypervisor-management paths that depend on accurate MSR handling.That still matters. Cloud providers, CI farms, lab environments, security sandboxes, and developer workstations increasingly rely on nested virtualization. A Windows-on-Linux test rig using KVM, a Kubernetes node running VM-based isolation, or a virtualization cluster that supports live migration can all depend on precise state transfer in ways that only become visible when something breaks.
The most obvious symptom class would be correctness failure rather than compromise: lost or incorrect branch-record state after migration, snapshot restore, or nested guest transitions. But security boundaries are built out of correctness. If userspace VMMs cannot enumerate and restore the CPU state they are responsible for, they may make decisions based on incomplete information.
That is why kernel CVEs often frustrate people outside the kernel world. They do not always map cleanly to “attacker does X, gains Y.” Sometimes the vulnerability is that a subsystem violated the invariant other layers rely on. In virtualization, violated invariants are the beginning of many worse stories.
Why This Lands on WindowsForum
A Linux KVM CVE belongs on a Windows-focused site because Windows is not just an operating system you boot on a laptop. It is a guest OS in clouds, a workload in labs, a target in enterprise virtualization, and a participant in increasingly mixed infrastructure. Many Windows admins now administer Windows Server guests running on Linux/KVM hosts, whether directly, through a cloud provider, or inside a developer platform that hides the Linux layer.The Windows angle is especially obvious for nested virtualization. Developers run Hyper-V, WSL, Android emulators, container stacks, and test VMs in configurations that may pass through multiple virtualization layers. Enterprises run Windows guests on non-Microsoft hypervisors for cost, density, or platform reasons. Security researchers routinely nest Windows targets inside Linux/KVM environments.
If the host hypervisor mishandles CPU debug or branch-history state, the Windows guest may not “know” it is affected. But the reliability of VM pause, resume, migration, snapshotting, debugging, and nested execution is still part of the Windows workload’s trust model. The guest does not need to carry the vulnerable code to suffer from a host-level virtualization defect.
This is also why patch triage should not stop at OS branding. A Windows estate may have no vulnerable Linux endpoints and still depend on vulnerable Linux hypervisors. Conversely, a Linux desktop user who never enables KVM, never runs nested virtualization, and never exposes LBR virtualization may have little practical exposure beyond the ordinary need to stay current.
The CVE Pipeline Is Turning Kernel Fixes Into Security Events
The Linux kernel project has been assigning CVEs to many resolved kernel flaws, including bugs that older vulnerability programs might have treated as ordinary stability fixes. That has changed the rhythm of patch management. Security teams now see a steady stream of kernel CVEs whose descriptions read like commit messages because, in many cases, they are essentially commit messages.CVE-2026-46014 fits that pattern. The record was received from kernel.org, the NVD page was published and last modified on May 27, 2026, and enrichment had not yet added scoring or weakness classification. The public references point to stable kernel commits rather than a vendor advisory with polished impact language.
That is not a defect in the process. It is a transparency tradeoff. Defenders get earlier visibility into kernel fixes that may have security implications, but they also get less packaging. Instead of a neat vendor severity badge, they get subsystem names, register names, commit hashes, and enough ambiguity to require actual engineering judgment.
For IT shops, this means vulnerability management must become more context-aware. A CVE affecting KVM’s SVM path should not be treated the same way on a desktop with no virtualization features enabled, a cloud host running untrusted tenants, and a lab box doing nested hypervisor testing. The scanner result is the start of the triage, not the end.
Patch Fastest Where Guests Are Mobile, Nested, or Untrusted
The practical advice is straightforward: update affected Linux kernels through the distribution or platform channel that supplies your KVM host kernel. The upstream fixes have landed in stable commit references, and downstream distributions will decide how to backport, package, and describe the issue. Administrators should track their vendor advisories rather than manually cherry-picking kernel patches unless they already operate a custom kernel process.Priority should be highest for hosts that run untrusted guests, support nested virtualization, rely on live migration or suspend/resume, or expose advanced CPU profiling/debug features to guests. Those are the environments where broken save-and-restore behavior is most likely to cross from theoretical to operationally meaningful. If you run single-purpose trusted VMs with no nested virtualization and a conservative CPU feature mask, the urgency is lower, but the fix still belongs in the normal kernel update train.
The one operational trap is reboot discipline. Kernel fixes do not protect a running host until the fixed kernel is booted, unless a live-patching vendor explicitly covers the affected code path. Many organizations “install” kernel updates but defer reboots for weeks. For hypervisor hosts, that can create a false sense of closure in vulnerability dashboards.
There is also a migration wrinkle. If your fleet mixes fixed and unfixed KVM hosts, VM movement can become the place where state bugs show up. That does not mean every cluster must be drained immediately, but it does argue for patching virtualization pools coherently rather than sprinkling updates across hosts at random.
The Register Names Are Ugly, but the Lesson Is Clean
This CVE is dense because the abstractions are dense.KVM_GET_MSR_INDEX_LIST is how userspace learns which MSRs KVM can save and restore. KVM_SET_MSRS is how userspace writes MSR values back. MSR_IA32_DEBUGCTLMSR controls debug-related behavior, while the MSR_IA32_LAST* family is tied to last-branch and last-interrupt tracking. VMCB state is AMD SVM’s control block world, and nested virtualization multiplies the number of places that state can hide.Strip away the jargon and the lesson is simple: a hypervisor must faithfully virtualize the CPU features it exposes. If a feature is visible to the guest and relevant to execution, the hypervisor must know how to preserve it across the lifecycle of a VM. Anything else is a trap for management software, nested hypervisors, and forensic assumptions.
That is why the fix allows userspace writes to LBR MSRs only when LBR virtualization is enabled. KVM is not simply opening a write-anything path to read-only hardware registers. It is giving trusted userspace VMMs a way to restore guest-visible virtual state under the conditions where that state is supposed to exist.
That distinction matters. Hypervisor userspace is not an arbitrary app in this model; it is part of the virtualization stack. QEMU and similar VMM components rely on kernel interfaces to snapshot and rebuild the guest CPU model. If the kernel does not expose the relevant pieces, userspace cannot do the right thing even if it wants to.
The Patch Notes Tell Admins Where to Look
The affected area is narrow enough that defenders can make a sensible triage call. This is KVM on x86, with special relevance to AMD SVM LBR virtualization and nested virtualization behavior. It is not a flaw in the Windows kernel, not a browser issue, and not a network-service bug that scans the Internet.The visible commit history also tells a useful story. The patch went through multiple revisions in the kernel mailing-list process, with discussion around reserved bits, userspace behavior, and the correct guard conditions for LBR virtualization. That is normal kernel work, but it is also evidence that this was not a drive-by one-line fix. The maintainers were refining the boundary between guest state, userspace restoration, and hardware semantics.
For enterprise teams, the right inventory question is not “Do we have CVE-2026-46014?” in isolation. It is “Which systems run KVM hosts, which of those expose nested virtualization or advanced CPU features, and which of those host workloads we do not fully trust?” The answer determines whether this is a routine maintenance item or a near-term hypervisor patch.
For Windows-heavy teams, the question is slightly different: “Where do our Windows workloads sit on Linux/KVM infrastructure we do not patch directly?” That may mean public cloud, private cloud, managed hosting, VDI, or lab environments. If someone else owns the host, the action is to check provider advisories and maintenance windows, not to patch the Windows guest.
This Is a Low-Drama CVE With High-Discipline Implications
CVE-2026-46014 will probably not become famous. It has no catchy name, no logo, no public score yet, and no obvious mass-exploitation story. It belongs to the less glamorous category of virtualization bugs that reward disciplined patching and punish vague asset inventories.The concrete takeaways are narrow but useful:
- The vulnerability was published by NVD on May 27, 2026, and was still awaiting NVD enrichment when reviewed.
- The flaw affects Linux KVM’s handling of LBR and debug-control MSR save-and-restore behavior, especially in the AMD SVM path.
- The upstream fix adds the missing MSRs to KVM’s save list and permits userspace restoration of LBR MSRs when LBR virtualization is enabled.
- Nested virtualization is the most interesting operational angle because the fix also copies LBR state from the captured VMCB01 save area while an L2 guest is running.
- Intel VMX receives a related correction for reporting
MSR_IA32_DEBUGCTLMSRas save-and-restore state, but the headline issue remains KVM’s SVM-side LBR handling. - Windows guests can be affected operationally when they run on vulnerable Linux/KVM hosts, even though the vulnerable code is not in Windows itself.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-28T01:09:40-07:00
NVD - CVE-2026-46014
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-28T01:09:40-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: spinics.net
Re: [PATCH v6 03/31] KVM: SVM: Add missing save/restore handling of LBR MSRs — Linux Kernel
Linux Kernel: Re: [PATCH v6 03/31] KVM: SVM: Add missing save/restore handling of LBR MSRs
www.spinics.net
- Related coverage: opennet.ru
- Related coverage: lists-ec2.96boards.org
- Related coverage: patchew.org
- Related coverage: cve.imfht.com
CVE-2025-46014: Several services in Honor Device Co., Ltd Honor PC Manager
## Vulnerability Overview In Honor PC Manager v16.0.0.118 by Honor Device Co., Ltd., multiple services connect to the named pipe `iMateBookAssistant`. Due to default or overly permissive security at
cve.imfht.com