Bug 2555189 (CVE-2026-98714)

Summary:	CVE-2026-98714 kernel: KVM: SVM: Update control fields on #VMEXIT if and only if VMRUN succeeded
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	akhatavk, aos-team-art-private, asdas, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the Linux kernel's KVM (Kernel-based Virtual Machine) subsystem for AMD processors (SVM). When virtual machine execution fails, the hypervisor prematurely updates control fields and marks control blocks as clean, assuming hardware operations were performed. A local attacker could leverage this behavior to cause state desynchronization between KVM and the processor, leading to system instability or unexpected guest behavior.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-10-18 15:59:50 UTC

In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: Update control fields on #VMEXIT if and only if VMRUN succeeded

Leave control.erap_ctl and control.clean as-is in the VMCS if VMRUN fails,
because as per AMD:

  there's no explicit architectural guarantee about the behavior in the
  presence of VMRUN failures. So the best thing to do would be to assume
  that if VMRUN fails, the actions requested in the control fields may not
  have been performed.