CVE-2026-46082

What it actually does

This is a Linux kernel KVM vulnerability in the AMD SVM virtualization path. The INVLPGA instruction should raise an undefined-instruction exception (#UD) when AMD Secure Virtual Machine support is not enabled in EFER.SVME. Vulnerable kernels fail to enforce that architectural check correctly, which can let a local attacker with the ability to run code in a guest or otherwise reach the KVM SVM path trigger incorrect kernel behavior. The assessed impact is denial of service, with no expected confidentiality or integrity impact.

Why it matters to the business

Systems running affected Linux kernels with KVM virtualization on AMD SVM-capable hardware may be exposed to a host availability risk from local or guest-level abuse. Successful exploitation could crash or destabilize virtualization hosts, interrupting virtual machines, services, workloads, and maintenance operations. The public exploitation signal is currently low: EPSS is 0.00123, no known CISA KEV listing, no ransomware association, and no known mature public exploit indicated. However, because the issue affects the kernel virtualization layer, organizations operating multi-tenant or untrusted guest workloads should prioritize remediation more highly than general-purpose single-user systems.

How an attack unfolds

An attacker first needs local execution capability sufficient to interact with the vulnerable KVM SVM code path, most plausibly by running code inside a virtual machine hosted on an affected Linux kernel using AMD SVM. The attacker crafts execution so that INVLPGA is encountered while EFER.SVME is not set. Correct behavior would be for KVM to inject #UD into the guest. On vulnerable kernels, the missing or incorrect check can cause KVM to mishandle the instruction state, resulting in host-side instability or crash conditions. The practical result is a denial-of-service event against the affected virtualization host or its guest workloads rather than data theft or privilege escalation.

How to fix it

Apply vendor kernel updates that include the KVM SVM fix for proper #UD injection when INVLPGA is executed with EFER.SVME=0. No exact fixed package versions were provided in the input, so use the latest patched kernel from the applicable Linux distribution or kernel vendor and reboot into the updated kernel. For systems where immediate patching is not possible, reduce exposure by limiting who can launch or control KVM guests, avoiding untrusted guest workloads on AMD SVM hosts, live-migrating sensitive workloads away from unpatched hosts where feasible, and disabling KVM/virtualization functionality on systems that do not require it. Mitigations should be treated as temporary because this is a kernel correctness flaw best resolved by updating the kernel.

How to confirm the fix worked

Confirm the system is running a kernel build that includes the upstream KVM SVM fix titled 'KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0' or the corresponding downstream distribution advisory. Verify after reboot with the active kernel version, not only the installed package version. For virtualization hosts, confirm KVM modules are loaded from the updated kernel and that guests were restarted or migrated as needed after host patching. If source or changelog validation is available, check for code that explicitly injects #UD for INVLPGA when EFER.SVME is clear. Operationally, monitor patched hosts for absence of recurring KVM/SVM-related kernel oops, panic, or VM crash events under representative workload testing.

Typical attack path

1. Obtain the ability to run local code in a VM or local context that can reach KVM's AMD SVM handling path.
2. Confirm the target is using a vulnerable Linux kernel with KVM enabled on AMD virtualization-capable hardware.
3. Execute or trigger an INVLPGA instruction sequence while EFER.SVME is not enabled.
4. Cause the vulnerable kernel path to mishandle the instruction instead of injecting #UD into the guest.
5. Induce host kernel instability, KVM failure, VM termination, or a broader denial-of-service condition.

How to detect it

There is no reliable network IOC for this vulnerability because exploitation is local or guest-to-host and manifests primarily as kernel or virtualization instability. To check for possible prior exploitation, review host-level kernel logs, hypervisor logs, crash dumps, and monitoring alerts for unexplained KVM/SVM-related panics, oops events, VM resets, or host reboots. Useful sources include journald, syslog, dmesg output, kernel crash dump directories, hypervisor management logs, and infrastructure monitoring events around unexpected host downtime. Focus on AMD-based KVM hosts and correlate crashes with activity from newly created, untrusted, or suspicious guest workloads. Look for kernel messages mentioning KVM, SVM, invalid opcode handling, INVLPGA, general protection faults, oops, panic, or sudden termination of qemu-kvm processes. Absence of these artifacts does not prove non-exploitation because a denial-of-service attempt may leave only generic crash or reboot evidence.

• INVLPGA
• KVM: SVM
• svm
• kvm_amd
• invalid opcode
• Undefined instruction
• Oops:
• kernel panic
• BUG: unable to handle kernel
• general protection fault
• qemu-kvm
• /var/crash/
• /var/lib/systemd/coredump/
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory Linux systems running KVM virtualization on AMD SVM-capable hardware and prioritize those hosting untrusted, multi-tenant, externally managed, or high-availability workloads.
• Patch affected systems using the appropriate vendor kernel update and reboot into the fixed kernel.
• If patching must be delayed, restrict the ability to create, import, or run untrusted guest images on affected hosts.
• Review recent host availability incidents, kernel panics, and guest crash events for KVM/SVM-related evidence that could indicate attempted triggering.
• Ensure virtualization hosts have centralized kernel logging, crash dump collection, and alerting for kernel oops or panic conditions.
• Because this is not currently in CISA KEV, has no ransomware association, and has very low EPSS, handle as a normal-priority kernel DoS issue unless the environment runs untrusted guest workloads, in which case escalate priority.