===================================================================== CERT-Renater Note d'Information No. 2022/VULN037 _____________________________________________________________________ DATE : 27/01/2022 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-393.html https://xenbits.xen.org/xsa/advisory-394.html https://xenbits.xen.org/xsa/advisory-395.html _____________________________________________________________________ Xen Security Advisory CVE-2022-23033 / XSA-393 version 2 arm: guest_physmap_remove_page not removing the p2m mappings UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The functions to remove one or more entries from a guest p2m pagetable on Arm (p2m_remove_mapping, guest_physmap_remove_page, and p2m_set_entry with mfn set to INVALID_MFN) do not actually clear the pagetable entry if the entry doesn't have the valid bit set. It is possible to have a valid pagetable entry without the valid bit set when a guest operating system uses set/way cache maintenance instructions. For instance, a guest issuing a set/way cache maintenance instruction, then calling the XENMEM_decrease_reservation hypercall to give back memory pages to Xen, might be able to retain access to those pages even after Xen started reusing them for other purposes. IMPACT ====== A malicious guest may be able to access Xen and other domains' memory. This could cause information leaks, host or domain Denial of Service (DoS), and privilege escalations. VULNERABLE SYSTEMS ================== Xen version 4.12 and newer are vulnerable. Only Arm systems are vulnerable. x86 systems are not vulnerable. MITIGATION ========== There is no known mitigation. CREDITS ======= This issue was discovered by Dmytro Firsov of EPAM. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa393.patch xen-unstable - Xen 4.12.x $ sha256sum xsa393* ccd746687c6080ec00ba363477d8815bc648d957c21c47d3a5330be9251806a4 xsa393.meta 89e5d66c437bacbe344e72d15720c1dde98dd97fab7184c7a6ff32bb63d442dd xsa393.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html _____________________________________________________________________ Xen Security Advisory CVE-2022-23034 / XSA-394 version 3 A PV guest could DoS Xen while unmapping a grant UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= 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. IMPACT ====== Malicious guest kernels may be able to mount a Denial of Service (DoS) attack affecting the entire system. VULNERABLE SYSTEMS ================== All Xen versions from at least 3.2 onwards are vulnerable in principle, if they have the XSA-380 fixes applied. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only x86 PV guests with access to PCI devices can leverage the vulnerability. x86 HVM and PVH guests, as well as PV guests without access to PCI devices, cannot leverage the vulnerability. Additionally from Xen 4.13 onwards x86 PV guests can leverage this vulnerability only when being granted access to pages owned by another domain. MITIGATION ========== Not running PV guests will avoid the vulnerability. For Xen 4.12 and older not passing through PCI devices to PV guests will avoid the vulnerability. For Xen 4.13 and newer not enabling PCI device pass-through for PV guests will avoid the vulnerability. This can be achieved via omitting any "passthrough=..." and "pci=..." settings from xl guest configuration files, or by setting "passthrough=disabled" there. - From Xen 4.13 onwards, XSM SILO can be available as a security policy designed to permit guests to only be able to communicate with Dom0. Dom0 does not normally offer its pages for guests to map, which means the use of SILO mode normally mitigates the vulnerability. CREDITS ======= This issue was discovered by Julien Grall of Amazon. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa394.patch xen-unstable - Xen 4.13.x xsa394-4.12.patch Xen 4.12.x $ sha256sum xsa394* 93f4d3b58d49ba239115753c9905b7c3720b438c48ef8fb701f15081aa317159 xsa394.meta f2a3420e8d3eb1cf728f90d3c352ace0d3c67f7933201ce9b784d63afaeaa179 xsa394.patch ee93797546ac9e82f98211366f9acc733332b0d5ab7ef73840c2acd2bb1439ca xsa394-4.12.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public- facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigations described above is NOT permitted during the embargo on public-facing systems with untrusted guest users and administrators. This is because such a configuration change is recognizable by the affected guests. AND: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html _____________________________________________________________________ Xen Security Advisory CVE-2022-23035 / XSA-395 version 2 Insufficient cleanup of passed-through device IRQs UPDATES IN VERSION 2 ==================== Adjust patch subject. Public release. ISSUE DESCRIPTION ================= 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. IMPACT ====== The precise impact is system specific, but would typically be a Denial of Service (DoS) affecting the entire host. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS ================== Xen versions 4.6 and later are vulnerable. Xen versions 4.5 and earlier are not vulnerable. Only x86 HVM guests with one or more passed-through physical devices using (together) multiple physical interupts can leverage the vulnerability. x86 PV guests cannot leverage the vulnerability. x86 HVM guests without passed-through devices or with a passed-through device using just a single physical interrupt also cannot leverage the vulnerability. Device pass-through is unsupported for x86 PVH guests and all Arm guests. MITIGATION ========== There is no mitigation (other than not passing through to x86 HVM guests PCI devices with, overall, more than a single physical interrupt). CREDITS ======= This issue was discovered by Julien Grall of Amazon. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa395.patch xen-unstable - Xen 4.15.x xsa395-4.14.patch Xen 4.14.x - Xen 4.12.x $ sha256sum xsa395* f460be598b936bb5cfb9276787f2f21d90b029d1fe10dabd572ae50f84a1124d xsa395.meta 295b876c52cf5efe19150757275da3d154beb72ac2d7be267e16c9262e410de3 xsa395.patch 5697f3137e0a202744f31b1c6cbcfa459d8fa9b4b68be59561b78c40fe1233c5 xsa395-4.14.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================