CVE-2026-43483

What it actually does

This is a Linux kernel KVM vulnerability in the AMD SVM virtualization path. When Advanced Virtual Interrupt Controller (AVIC) is activated or deactivated, KVM can fail to correctly clear or set CR8 write interception. That leaves a stale CR8 intercept active after AVIC is enabled. By itself this can cause unnecessary VM exits and degraded guest performance; combined with related TPR synchronization behavior, the virtual task priority register state seen by hardware can become inconsistent with the guest’s actual LAPIC state, which can be fatal to affected Windows guests. The practical technical impact is guest instability or denial of service on AMD-based KVM hosts using AVIC, not data disclosure or privilege escalation.

Why it matters to the business

Organizations running Linux KVM virtualization on affected AMD systems may experience guest operating system crashes, hangs, or severe performance degradation, especially for Windows virtual machines. This can disrupt hosted workloads, cause service outages, trigger failover events, and reduce confidence in virtualization platform stability. The issue has a moderate CVSS score and very low EPSS, is not listed in CISA KEV, and has no known exploit maturity in the supplied data, so broad internet-driven exploitation is unlikely; however, local users or tenants able to run or influence guest workloads could intentionally trigger instability in shared virtualization environments.

How an attack unfolds

An attacker needs local or tenant-level ability to run or control a virtual machine on an affected Linux KVM host using AMD SVM with AVIC. The attacker exercises guest behavior that causes KVM to emulate states such as INIT-to-wait-for-SIPI while AVIC is deactivated, then causes AVIC activation with CR8 write interception left enabled. Subsequent CR8 writes generate unexpected VM exits even though AVIC is active. Under the affected synchronization conditions, the TPR value used by hardware can drift from the guest’s real LAPIC state. For Windows guests, this can result in fatal interrupt handling inconsistencies, leading to guest crashes, hangs, or sustained denial of service. The attacker does not need network access to the host and does not gain code execution on the host from this flaw alone.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the KVM SVM fix for correctly setting and clearing CR8 write interception when AVIC is activated or deactivated. Because no exact fixed versions were provided, follow the advisories for the relevant Linux distribution or kernel vendor and apply the latest stable or long-term kernel updates containing the upstream KVM SVM AVIC CR8 interception fix. Where immediate patching is not possible, consider disabling AVIC on affected AMD KVM hosts as a temporary mitigation, understanding this may reduce interrupt virtualization performance. Limit guest creation and administrative access on shared virtualization hosts, and avoid placing high-availability-sensitive Windows workloads on unpatched affected hosts.

How to confirm the fix worked

Confirm that affected hosts are running a patched kernel from the relevant distribution or a kernel build that contains the KVM SVM change to set and clear CR8 write interception during AVIC activation and deactivation. Validate exposure by identifying AMD-based KVM hosts with SVM and AVIC enabled, then compare their kernel package versions against vendor fixed builds. After patching, reboot into the updated kernel and verify KVM modules are loaded from the new kernel. Review kernel logs for absence of new KVM warnings related to CR8 write VM exits while AVIC is active, and perform controlled guest lifecycle testing, especially with Windows guests, to confirm that VM crashes or hangs no longer reproduce.

Typical attack path

1. Gain authorized or compromised access to run code inside a guest VM on an affected AMD-based KVM host.
2. Trigger guest CPU or interrupt-controller state transitions that cause KVM to emulate INIT-to-WFS or similar conditions while AVIC is deactivated.
3. Cause AVIC to be reactivated while the stale CR8 write intercept remains enabled.
4. Generate guest CR8 writes that unexpectedly exit to the hypervisor while AVIC is active.
5. Drive the guest’s virtual interrupt priority state out of sync with the hardware-visible TPR state.
6. Cause the affected guest, particularly a Windows guest, to hang, crash, or become unavailable.

How to detect it

This issue is primarily a denial-of-service condition and may not leave a unique exploitation fingerprint. Detection should focus on correlated evidence from Linux host kernel logs, hypervisor management logs, and affected guest operating system logs. On Linux KVM hosts, review dmesg, journald, syslog, kern.log, and virtualization platform logs for KVM SVM or AVIC warnings, unexpected CR8 write VM exits, repeated guest resets, and kernel WARN messages after guest interrupt or startup events. On Windows guests, review System event logs, bugcheck records, unexpected shutdown events, heartbeat loss, and repeated reboot cycles occurring while the host remains otherwise healthy. Look for clustering of crashes on AMD KVM hosts with AVIC enabled, especially after guest lifecycle events such as boot, reset, INIT/SIPI handling, migration, or CPU hotplug. Because no public exploit artifacts or named threat actors are provided, treat repeated guest crashes aligned with KVM SVM/AVIC warnings as suspicious but validate against known platform instability and patch status.

• KVM: SVM
• AVIC
• CR8 write
• CR8 write #VMEXIT
• WARN
• V_TPR
• TPR
• INIT=>WFS
• INIT-to-WFS
• avic_deactivate_vmcb
• unexpected shutdown
• bugcheck
• Event ID 41
• Event ID 1001

What your security team should do

• Prioritize patching AMD-based Linux KVM hypervisors that host Windows guests or multi-tenant workloads.
• Inventory virtualization hosts for AMD SVM/KVM usage and determine whether AVIC is enabled.
• Apply the latest vendor kernel security and stability updates, then reboot hosts into the fixed kernel.
• If patching must be delayed, evaluate temporarily disabling AVIC on affected hosts and monitor for performance impact.
• Restrict local shell access and VM management privileges on hypervisors to reduce opportunities for intentional triggering.
• Monitor kernel, hypervisor, and guest availability logs for KVM warnings, unexpected VM exits, Windows guest bugchecks, hangs, and repeated resets.
• Coordinate remediation with operations teams because kernel updates require host reboots and possible guest migration or maintenance windows.