Citrix Releases Security Updates for Hypervisor

Scheduled updates for Citrix Hypervisor

Threat ID:: CC-4035
Threat Severity:: Information only
Published:: 9 February 2022 10:45 AM

Report a cyber attack: call 0300 303 5222 or email [email protected]

Summary

Scheduled updates for Citrix Hypervisor

Affected platforms

The following platforms are known to be affected:

Versions: 8.2, 8.2 CU1 LTSR

Citrix Hypervisor

Versions: 7.1 CU2 LTSR

Citrix XenServer

Threat details

Introduction

Citrix has released security updates to address vulnerabilities in Hypervisor. An attacker could exploit these vulnerabilities to take control of an affected system.

Remediation advice

Affected organisations are encouraged to review Citrix Security Update CTX337526 and install the relevant hotfixes.

Remediation steps

Type	Step
Patch	Hotfix XS82ECU1003 - For Citrix Hypervisor 8.2 Cumulative Update 1 https://support.citrix.com/article/CTX338451
Patch	Hotfix XS82E037 - For Citrix Hypervisor 8.2 https://support.citrix.com/article/CTX338452
Patch	Hotfix XS71ECU2071 - For XenServer 7.1 Cumulative Update 2 https://support.citrix.com/article/CTX338453

Definitive source of threat updates

https://support.citrix.com/article/CTX337526

CVE Vulnerabilities

Status Published

CVE-2022-23034

A PV guest could DoS Xen while unmapping a grant To address XSA-380, reference counting was introduced for grant mappings for the case where a PV guest would have the IOMMU enabled. PV guests can request two forms of mappings. When both are in use for any individual mapping, unmapping of such a mapping can be requested in two steps. The reference count for such a mapping would then mistakenly be decremented twice. Underflow of the counters gets detected, resulting in the triggering of a hypervisor bug check.

Status Published

CVE-2022-23035

Insufficient cleanup of passed-through device IRQs The management of IRQs associated with physical devices exposed to x86 HVM guests involves an iterative operation in particular when cleaning up after the guest's use of the device. In the case where an interrupt is not quiescent yet at the time this cleanup gets invoked, the cleanup attempt may be scheduled to be retried. When multiple interrupts are involved, this scheduling of a retry may get erroneously skipped. At the same time pointers may get cleared (resulting in a de-reference of NULL) and freed (resulting in a use-after-free), while other code would continue to assume them to be valid.

Last edited: 9 February 2022 10:58 am