GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel KVM on AMD: stale CR8 write intercept after AVIC activation desynchronises guest TPR

CVSS 5.5CVE-2026-43483Kernel, userspace & hypervisorcurated

Impact

KVM on AMD hosts failed to clear CR8 write interception when AVIC was activated, so a guest that goes through INIT then wait-for-SIPI while AVIC is deactivated keeps CR8 intercepted forever. On its own that is a performance tax, but combined with the earlier TPR sync defect it leaves the task priority register hardware sees wildly out of step with the guest's view, which is fatal to Windows guests. For an operator running GPU VMs with passthrough accelerators on EPYC hosts this shows up as guests hanging or crashing with no obvious host-side cause; the published vector scores it availability-only (C:N/I:N/A:H). Intel hosts are not affected - this is specific to the SVM/AVIC path.

Who can reach it

Local to the host, authenticated: a guest that can drive its own vCPUs through INIT/SIPI transitions while AVIC is toggled. No host credentials are needed beyond the ability to run a VM; a tenant VM on a shared hypervisor is enough.

What to do

Update to a stable kernel that explicitly sets and clears CR8 write interception on AVIC (de)activation and warns on a CR8 #VMEXIT while AVIC is active. It is a host kernel change, so plan to live-migrate or shut down the guests, reboot the hypervisor onto the fixed kernel, and bring workloads back; disabling AVIC (avic=0) avoids the inconsistent state at a performance cost if a reboot cannot be scheduled yet.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.