Bug 2477073 (CVE-2026-43483) - CVE-2026-43483 kernel: KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated
Summary: CVE-2026-43483 kernel: KVM: SVM: Set/clear CR8 write interception when AVIC i...
Keywords:
Status: NEW
Alias: CVE-2026-43483
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-05-13 16:02 UTC by OSIDB Bzimport
Modified: 2026-05-13 17:19 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-05-13 16:02:39 UTC
In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated

Explicitly set/clear CR8 write interception when AVIC is (de)activated to
fix a bug where KVM leaves the interception enabled after AVIC is
activated.  E.g. if KVM emulates INIT=>WFS while AVIC is deactivated, CR8
will remain intercepted in perpetuity.

On its own, the dangling CR8 intercept is "just" a performance issue, but
combined with the TPR sync bug fixed by commit d02e48830e3f ("KVM: SVM:
Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active"), the danging
intercept is fatal to Windows guests as the TPR seen by hardware gets
wildly out of sync with reality.

Note, VMX isn't affected by the bug as TPR_THRESHOLD is explicitly ignored
when Virtual Interrupt Delivery is enabled, i.e. when APICv is active in
KVM's world.  I.e. there's no need to trigger update_cr8_intercept(), this
is firmly an SVM implementation flaw/detail.

WARN if KVM gets a CR8 write #VMEXIT while AVIC is active, as KVM should
never enter the guest with AVIC enabled and CR8 writes intercepted.

[Squash fix to avic_deactivate_vmcb. - Paolo]


Note You need to log in before you can comment on or make changes to this bug.