CVE-2026-46014

What it actually does

This is a Linux kernel KVM virtualization flaw in save/restore handling for Last Branch Record (LBR) and DEBUGCTL model-specific registers. On affected kernels, KVM does not correctly enumerate or restore these MSRs for virtual CPUs, and nested SVM state can lose or mishandle LBR state during VMRUN transitions. A local user with permission to use KVM can potentially trigger inconsistent vCPU state handling during VM creation, save/restore, migration, or nested virtualization activity, leading primarily to denial of service or instability of the affected host or virtual machine workloads. The CVSS vector indicates local access, low attack complexity, low privileges, no user interaction, unchanged scope, and high availability impact, with no direct confidentiality or integrity impact described.

Why it matters to the business

Organizations using Linux KVM for virtualization may experience VM crashes, failed migrations, host instability, or service disruption if unpatched systems are exposed to untrusted users or workloads with access to KVM. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no public exploit maturity indicated, so broad internet-scale exploitation is unlikely; however, multi-tenant virtualization hosts, CI runners, developer workstations, lab platforms, and systems allowing untrusted users to run KVM guests should treat it as an availability risk.

How an attack unfolds

An attacker first needs local access to a Linux system and permission to interact with KVM, typically through membership in a virtualization-related group, access to /dev/kvm, or control of a VM workload on a host that exposes KVM functionality. The attacker then runs or manipulates a guest, nested guest, or VM lifecycle operation that exercises LBR/debug MSR state, especially around vCPU save/restore, snapshot, migration, or nested SVM execution. Because affected kernels do not correctly report and restore the relevant MSRs, KVM can enter an inconsistent state when restoring vCPU execution context. The practical outcome is expected to be denial of service, such as VM failure, migration failure, kernel warnings, KVM module faults, or host instability, rather than data theft or privilege escalation based on the published description.

How to fix it

Update affected Linux kernel packages to a vendor release that includes the upstream fix for KVM LBR and DEBUGCTL MSR save/restore handling. No exact fixed package versions were provided in the input, so use distribution advisories and kernel changelogs to identify the patched build for each Linux distribution in use. After updating, reboot into the patched kernel and ensure KVM modules are reloaded from the updated kernel. Where immediate patching is not possible, reduce exposure by restricting /dev/kvm access to trusted administrators and trusted automation only, disabling nested virtualization where not required, preventing untrusted users from launching KVM guests, and avoiding untrusted VM save/restore or migration workflows on affected hosts.

How to confirm the fix worked

Confirm that systems are running a patched kernel by checking the active kernel version with uname -r and comparing it against the relevant Linux distribution security advisory or kernel changelog. Validate that the patch containing the KVM fix for missing save/restore handling of LBR MSRs is present. Confirm that kvm_intel or kvm_amd modules were reloaded after reboot and are from the patched kernel. Functional validation can include testing VM start, stop, suspend/resume, snapshot restore, live migration, and nested virtualization workflows while monitoring kernel, QEMU, and libvirt logs for KVM MSR errors, warnings, or crashes. Exposure validation should also verify that only trusted users or service accounts can access /dev/kvm.

Typical attack path

1. Obtain local access to a Linux system where KVM is enabled.
2. Gain permission to open /dev/kvm or run virtual machines through QEMU, libvirt, a CI runner, or another virtualization interface.
3. Create or control a VM or nested VM that exercises DEBUGCTL/LBR-related CPU state.
4. Trigger VM save/restore, migration, snapshot, suspend/resume, or nested virtualization transitions.
5. Cause KVM to mishandle LBR/debug MSR state during restore or nested VMRUN handling.
6. Induce VM disruption, failed lifecycle operations, kernel errors, or host availability impact.

How to detect it

There are no public threat actors, KEV listing, ransomware use, or mature public exploit reports associated with this issue in the provided data. Detection should focus on signs of local abuse of KVM and unexplained availability failures around VM state transitions. Review systemd journal, syslog, kern.log, dmesg, auditd, libvirt logs, and QEMU logs for KVM MSR access failures, VM save/restore or migration failures, kernel warnings, kernel Oops events, host reboots, or repeated crashes involving kvm_amd, kvm_intel, SVM, VMX, DEBUGCTL, or LBR. Audit access to /dev/kvm and look for unexpected users, shells, containers, CI jobs, or processes launching qemu-system or issuing KVM ioctls. Correlate suspicious local user activity with VM suspend/resume, snapshot restore, live migration, nested virtualization testing, or abrupt VM/host failures. Because this vulnerability does not provide a unique network signature, host telemetry and virtualization logs are the primary detection sources.

• /dev/kvm
• qemu-system-x86_64
• qemu-system-i386
• libvirtd
• virtqemud
• kvm_amd
• kvm_intel
• KVM_SET_MSRS
• KVM_GET_MSR_INDEX_LIST
• MSR_IA32_DEBUGCTLMSR
• IA32_DEBUGCTL
• MSR_IA32_LASTBRANCH
• LASTBRANCH
• LBR
• VMRUN
• svm_copy_vmrun_state
• kvm: disabled by bios
• KVM: entry failed
• KVM: unknown MSR
• failed to set MSR
• failed to get MSR
• kvm_amd:
• kvm_intel:
• kernel BUG at
• general protection fault
• Oops:
• QEMU: Terminated
• operation failed: migration
• operation failed: restore

What your security team should do

• Inventory Linux systems running KVM, QEMU, libvirt, nested virtualization, CI virtualization runners, or developer virtualization workloads.
• Prioritize patching multi-tenant virtualization hosts and any systems where untrusted users can access /dev/kvm.
• Apply the vendor kernel update that includes the KVM LBR MSR save/restore fix, then reboot into the patched kernel.
• Restrict /dev/kvm permissions to trusted users and remove unnecessary users from virtualization-related groups.
• Disable nested virtualization unless there is a clear operational requirement.
• Monitor kernel, libvirt, and QEMU logs for KVM MSR access errors, failed VM restore/migration events, kernel Oops messages, or unexpected host/VM crashes.
• Treat suspicious KVM activity from nonstandard local users or unexpected processes as potentially malicious, even though no known exploitation is currently reported.
• Track vendor advisories because fixed package names and versions vary by Linux distribution.