CVE-2026-43483: Linux Kernel Privilege Escalation Flaw

CVE-2026-43483 Overview

CVE-2026-43483 is a Linux kernel vulnerability in the KVM Secure Virtual Machine (SVM) subsystem. The flaw resides in how KVM handles CR8 write interception when the Advanced Virtual Interrupt Controller (AVIC) is activated or deactivated. KVM fails to explicitly clear the CR8 write interception after AVIC activation, leaving the interception enabled indefinitely. When combined with a previously fixed Task Priority Register (TPR) synchronization bug, the dangling interception causes hardware TPR state to diverge from the guest's view. This condition is fatal to Windows guests running on affected hypervisors. The bug is specific to AMD SVM and does not affect Intel VMX, which ignores TPR_THRESHOLD when Advanced Programmable Interrupt Controller virtualization (APICv) is active.

Critical Impact
Dangling CR8 write interception on AMD SVM hosts can cause Windows guest virtual machines to crash or hang when AVIC is dynamically toggled, producing a denial-of-service condition for hosted workloads.

Affected Products

Linux kernel versions containing the KVM SVM AVIC implementation prior to the referenced stable patch commits
AMD-based hypervisor hosts using KVM with AVIC enabled
Windows guest virtual machines hosted on affected KVM/SVM systems

Discovery Timeline

2026-05-13 - CVE-2026-43483 published to NVD
2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-43483

Vulnerability Analysis

The vulnerability exists in KVM's AMD SVM implementation, specifically in the handling of CR8 write interception state transitions tied to AVIC activation. AVIC accelerates interrupt delivery to guests by allowing hardware to manage the virtual APIC without VMEXITs. When KVM enables AVIC, CR8 writes should no longer be intercepted because hardware manages the TPR directly. KVM was failing to clear the CR8 write interception bit when transitioning AVIC from deactivated to activated. For example, when KVM emulated an INIT followed by a Wait-for-SIPI while AVIC was deactivated, CR8 remained intercepted permanently afterward.

Root Cause

The root cause is missing state synchronization between AVIC activation logic and the VMCB intercept bitmap. The avic_activate_vmcb and avic_deactivate_vmcb paths did not explicitly set or clear the CR8 write interception bit. As a result, intercept state inherited from prior guest execution leaked across AVIC transitions. On its own, the dangling intercept is a performance regression, but combined with the TPR sync issue fixed by commit d02e48830e3f, the hardware-visible TPR drifts from the guest-visible TPR, breaking interrupt priority handling.

Attack Vector

This is a kernel logic flaw triggered through legitimate virtualization workflows rather than a directly exploitable memory corruption vulnerability. A guest virtual machine performing operations that cause KVM to deactivate and reactivate AVIC, such as INIT and Wait-for-SIPI sequences during virtual CPU bring-up, can place the host into the bad intercept state. The result is guest instability, particularly for Windows guests that rely on accurate TPR semantics for interrupt scheduling. The fix adds an explicit WARN if KVM observes a CR8 write VMEXIT while AVIC is active, since this combination should be impossible after the fix is applied.

Detection Methods for CVE-2026-43483

Indicators of Compromise

Kernel warning messages from the KVM SVM subsystem indicating a CR8 write VMEXIT occurred while AVIC was active
Windows guest virtual machines on AMD hosts experiencing unexplained hangs, blue screens, or interrupt-related instability following virtual CPU INIT or reset events
Performance degradation in guests after AVIC activation due to unnecessary CR8 write VMEXITs

Detection Strategies

Query installed kernel package versions across the hypervisor fleet and compare against the patched stable kernel commits referenced in the advisory
Monitor dmesg and journalctl -k output on AMD KVM hosts for KVM AVIC-related warnings
Audit hosts where kvm_amd is loaded with the avic=1 module parameter, as only these systems exercise the vulnerable code path

Monitoring Recommendations

Track guest VM crash events and correlate with host kernel version and AVIC configuration
Centralize hypervisor kernel logs into a security data lake for cross-host pattern analysis
Alert on repeated Windows guest reboot loops on AMD KVM hosts, which can indicate the TPR desynchronization symptom

How to Mitigate CVE-2026-43483

Immediate Actions Required

Apply the upstream stable kernel patches referenced in the Kernel Patch Commit a4123fe5d9 and related commits across all AMD KVM hypervisor hosts
Inventory hypervisor hosts running kvm_amd with AVIC enabled and prioritize them for patching
Schedule live migration of Windows guest workloads off vulnerable hosts before reboot windows

Patch Information

The fix is distributed across six upstream stable kernel commits. Relevant references include Kernel Patch Commit 01651e7751, Kernel Patch Commit 737410b32b, Kernel Patch Commit 816fa1dfae, Kernel Patch Commit 87d0f901a9, Kernel Patch Commit a4123fe5d9, and Kernel Patch Commit ba3bca40f9. The patch explicitly sets and clears CR8 write interception in avic_activate_vmcb and avic_deactivate_vmcb and adds a WARN to catch future regressions.

Workarounds

Disable AVIC by loading the kvm_amd module with avic=0 until patches can be applied, accepting the performance trade-off
Avoid hosting latency-sensitive or interrupt-heavy Windows guests on AMD KVM hosts until the kernel is updated
Pin affected guests to Intel-based hypervisor hosts where the VMX implementation is not affected

bash

# Disable AVIC on AMD KVM hosts as a temporary workaround
sudo modprobe -r kvm_amd
sudo modprobe kvm_amd avic=0

# Persist the setting across reboots
echo 'options kvm_amd avic=0' | sudo tee /etc/modprobe.d/kvm-amd-avic.conf

# Verify AVIC is disabled
cat /sys/module/kvm_amd/parameters/avic