==================================================================== CERT-Renater Note d'Information No. 2020/VULN581 _____________________________________________________________________ DATE : 20/10/2020 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen versions up to and including 4.14, xen-unstable. ===================================================================== https://xenbits.xen.org/xsa/advisory-345.html https://xenbits.xen.org/xsa/advisory-346.html https://xenbits.xen.org/xsa/advisory-347.html _____________________________________________________________________ Xen Security Advisory XSA-345 version 3 x86: Race condition in Xen mapping code UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= The Xen code handling the updating of the hypervisor's own pagetables tries to use 2MiB and 1GiB superpages as much as possible to maximize TLB efficiency. Some of the operations for checking and coalescing superpages take non-negligible amount of time; to avoid potential lock contention, this code also tries to avoid holding locks for the entire operation. Unfortunately, several potential race conditions were not considered; precisely-timed guest actions could potentially lead to the code writing to a page which has been freed (and thus potentially already reused). IMPACT ====== A malicious guest can cause a host denial-of-service. Data corruption or privilege escalation cannot be ruled out. VULNERABLE SYSTEMS ================== Versions of Xen from at least 3.2 onward are affected. Only x86 systems are vulnerable. ARM systems are not vulnerable. Guests can only exercise the vulnerability if they have passed through hardware devices. Guests without passthrough configured cannot exploit the vulnerability. Furthermore, HVM and PVH guests can only exercise the vulnerability if they are running in shadow mode, and only when running on VT-x capable hardware (as opposed to SVM). This is believed to be Intel, Centaur and Shanghai CPUs. MITIGATION ========== Running all guests in HVM or PVH mode, in each case with HAP enabled, prevent those guests from exploiting the vulnerability. CREDITS ======= This issue was discovered by Hongyan Xia 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. xsa345/*.patch xen-unstable xsa345-4.14/*.patch Xen 4.14.x xsa345-4.13/*.patch Xen 4.12.x, Xen 4.13.x xsa345-4.11/*.patch Xen 4.11.x xsa345-4.10/*.patch Xen 4.10.x $ sha256sum xsa345* xsa345*/* c8b9445b05aa4c585d9817c2e6cbf08466452a15381ca5b9a0224a377522edf9 xsa345.meta 4ed69dce620449bedda29f3ce1ed767908d2bbeb888701e7c4c2461216b724f7 xsa345-4.10/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch 98d3b171b197c1ff9f26ff70499a0cde3b23d048d622b12bf2ea0899de4f9e7f xsa345-4.10/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 78c4be2f1747051d13869001180ee25bdeabe5e8138d0604a33db610b24e38f1 xsa345-4.10/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch 4abd8271a70593fcde683071fdf0ac342ff9b0859b60c9790b14dd7e5ae85129 xsa345-4.11/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch 3209195c1a7e8a6186b704d6bb791a3fb3c251d59e15b42bcb0ecc0d38f13a4f xsa345-4.11/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 7e73f6c14718a0d4b25b4453b45c20bf265bd54c91b77678815be1ef7beae61f xsa345-4.11/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch b68b82911c96feee9d05abcddf174c2f6b278829bc8c3bf3062739de8c4704b2 xsa345-4.12/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch fe2a1568a3e273ae01b3984c193e75aea16da53c6c9db27d21a2196d0f204c6e xsa345-4.12/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 22c98f4a264bc6b15ed29da8698a733947849c16a3e9da58de88bf16986b6aad xsa345-4.12/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch 16299d885c19e1cd378a856caf8c1d1365c341bea648c0a0d5f24ae7d56015ae xsa345-4.13/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch b820061c242c7fa4da44cbb44fa16e0d0542c16815a89699385da0c87321f7ea xsa345-4.13/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 8a87ac2478c9bda6ef28c480b256448d51393a5e04f6e8a68ea29d9aeba92e47 xsa345-4.13/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch acf093741fecccccce0018d4a5c0f5dba367373dd1d6d04ed76ff3f178579670 xsa345-4.14/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch 616f2547b4bb6d5eb9f853b1659e6e2a1fc0f67866665f4f6cdd8d763effcdfc xsa345-4.14/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 17ae72d2af6759da17ce777e0fc9eef8f8eb6be3fe6d5b38b3589f641fc0f918 xsa345-4.14/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.patch 65c56cb4d34ff4e97220311b303c09b54bfa44bcf4adc8e81d4a50c50eeb6b95 xsa345/0001-x86-mm-Refactor-map_pages_to_xen-to-have-only-a-sing.patch 5512bd167c29ba7da06b2ace1397fc43ed33a362174ea927d6ca3f9bdd31748b xsa345/0002-x86-mm-Refactor-modify_xen_mappings-to-have-one-exit.patch 392524c9b0a01618e6c86a39dc1c68288065300b49548e29e9e6672947858060 xsa345/0003-x86-mm-Prevent-some-races-in-hypervisor-mapping-upda.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 XSA-346 version 2 undue deferral of IOMMU TLB flushes UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= To efficiently change the physical to machine address mappings of a larger range of addresses for fully virtualized guests, Xen contains an optimization to coalesce per-page IOMMU TLB flushes into a single, wider flush after all adjustments have been made. While this is fine to do for newly introduced page mappings, the possible removal of pages from such guests during this operation should not be "optimized" in the same way. This is because the (typically) final reference of such pages is dropped before the coalesced flush, and hence the pages may have been put to a different use even though DMA initiated by their original owner mightstill be in progress. IMPACT ====== A malicious guest might be able to cause data corruption and data leaks. Host or guest Denial of Service (DoS), and privilege escalation, cannot be ruled out. VULNERABLE SYSTEMS ================== All Xen versions from 4.2 onwards are vulnerable. Xen versions 4.1 and earlier are not vulnerable. Only x86 HVM and PVH guests can leverage the vulnerability. Arm guests as well as x86 PV ones cannot leverage the vulnerability. Only x86 HVM and PVH guests which have physical devices passed through to them can leverage the vulnerability. Only x86 HVM and PVH guests configured to not share IOMMU and CPU page tables can leverage the vulnerability. Sharing these page tables is the default on capable Intel (VT-d) hardware. On AMD hardware sharing is not possible. On Intel (VT-d) hardware sharing may also not be possible, depending on hardware properties. Whether it is possible can be seen from the presence (or absence) of "iommu_hap_pt_share" on the "virt_caps" line of "xl info" output. Guests run in shadow mode can leverage the vulnerability. MITIGATION ========== Not passing through physical devices to untrusted guests will avoid the vulnerability. On systems permitting page table sharing, not suppressing use of the functionality will allow to avoid the vulnerability. This means guests should not be run in * shadow mode, i.e. hardware needs to be HAP (Hardware Assisted Paging) capable, there should not be "hap=0" in the guest's xl configuration file, and there should not be "hap=0" or equivalent on Xen's command line, * non-shared page table mode, i.e. hardware needs to be capable of sharing, there should not be "passthrough=sync_pt" in the guest's xl configuration file, and there should not be "iommu=no-sharept" or equivalent on Xen's command line. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate pair of attached patches 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. xsa346/xsa346-?.patch Xen 4.14 - xen-unstable xsa346/xsa346-4.13-?.patch Xen 4.13 xsa346/xsa346-4.12-?.patch Xen 4.12 xsa346/xsa346-4.11-?.patch Xen 4.11 xsa346/xsa346-4.10-?.patch Xen 4.10 $ sha256sum xsa346* xsa346*/* ba560d34cb46f45d6da0ba5d672cb896c173e90de5c022d22415ace20c5e47b8 xsa346.meta 5f8b3e5565bc7d87283af173f5f2b35975e4ab6bff502780799d14fb263f730d xsa346/xsa346-1.patch 9de89ca360f303e7aa3b42529cdf4191b0700ee7cb6928a22068195e047a4db7 xsa346/xsa346-2.patch f3612bfad219160917a3bc46ea5b31673137593d62ae4f819a8e80ade0339c5b xsa346/xsa346-4.10-1.patch 734ed82d583bbce342ffabeb9dd84e300f2717ec71e3de866670b0ddf18d57aa xsa346/xsa346-4.10-2.patch 7a41bf06e19590cfc69d4f2ac132a23843dcec2ea5f98d86c4be971f9eec86af xsa346/xsa346-4.11-1.patch 1359801b8f64ac62dc8de4e3acc15ec42c040f692f3a1ee9986acb478ee330cd xsa346/xsa346-4.11-2.patch 190f594bb77dd044af8f0a051ab1d4143c348da192206da9b390af91c0a2cdec xsa346/xsa346-4.12-1.patch 5bcb65dc45f6d74c644ee6b6add518044c9875e6759254773d3816e718c2be28 xsa346/xsa346-4.12-2.patch 69e0158276a922829eb60dc5bb13e60a71a232ace808843f45dac407716b107b xsa346/xsa346-4.13-1.patch eb8132a02c252dc65be1f334939f252db0c30ae2db8aa23f0d9e67f8148e2d2d xsa346/xsa346-4.13-2.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 is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because removal of pass-through devices or their replacement by emulated devices is a guest visible configuration change, which may lead to re-discovery of the issue. Similarly the possible guest configuration changes can't be excluded to be noticeable to guests. Deployment of this mitigation is permitted only AFTER the embargo ends. 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 XSA-347 version 2 unsafe AMD IOMMU page table updates UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= AMD IOMMU page table entries are updated in a step by step manner, without regard to them being potentially in use by the IOMMU. Therefore it was possible that the IOMMU would read and then use a half-updated entry. Furthermore, updates to Device Table entries lacked suitable ordering enforcement for certain steps involved in these updates. In both case the specific outcome heavily depends on how exactly the compiler translated the affected pieces of code. IMPACT ====== A malicious guest might be able to cause data corruption and data leaks. Host or guest Denial of Service (DoS), and privilege escalation, cannot be ruled out. VULNERABLE SYSTEMS ================== All Xen versions are potentially vulnerable. Only x86 systems with AMD, Hygon, or compatible IOMMU hardware are vulnerable. Arm systems as well as x86 systems with VT-d hardware or without any IOMMUs in use are not vulnerable. Only x86 guests which have physical devices passed through to them can leverage the vulnerability. MITIGATION ========== Not passing through physical devices to untrusted guests will avoid the vulnerability. CREDITS ======= This issue was discovered by Paul Durrant of Amazon and Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate set of attached patches 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. xsa347/xsa347-?.patch xen-unstable xsa347/xsa347-4.14-?.patch Xen 4.14 xsa347/xsa347-4.13-?.patch Xen 4.13 xsa347/xsa347-4.12-?.patch Xen 4.12 xsa347/xsa347-4.11-?.patch Xen 4.10 - 4.11 $ sha256sum xsa347* xsa347*/* f16e1a348b0e45601c96b2bd08afc4202bbccc92c8af8344b3c8286ca819acef xsa347.meta 82e14d0507ec94f8cfac2b4d5d1b60681b925218ab927332bee338e6b6c679c9 xsa347/xsa347-1.patch 1bc6018c3685727ba4035bf0b5cea95940a1b9c4746fa9bddfd41507482d68a1 xsa347/xsa347-2.patch f1bd8eba268300f564837ac37fe43b774ace885c9cbf8fcacae457128730bc80 xsa347/xsa347-3.patch 5aec8f3b15aa799e1ff7ec0dfe53523cb91aa5fd88033f7f034cb74ebaa6abe4 xsa347/xsa347-4.11-1.patch 4ab3a6fa181ce486b4c9943f6629b7c1a4337c7ccb92701ae6e40108533778ca xsa347/xsa347-4.11-2.patch fec82340dc65fc1001358de51d0639b2b401818fa1e831f8715cb1780b17dc7b xsa347/xsa347-4.12-1.patch be89e976fe03464ce3a73b162c07927128f41a8a03466e903ebfa4ea0dc46116 xsa347/xsa347-4.12-2.patch 5dc0abf73d1a9d21f2b57e6c57ee5c15cc3febbb783123c0946f3e5778671929 xsa347/xsa347-4.13-1.patch 6d2b6ea7a373fb1c4cce63db349bbafa8603b5e7c6b74fc6d029954075f2268d xsa347/xsa347-4.13-2.patch 4e154bfca5101569c8260e307eb6439783bc99547b7dfb5aba2bafebbde46190 xsa347/xsa347-4.13-3.patch 6a70c2afba0d3ad73b12743a6808ba8002e9ee573d7c460397355e40de3b553f xsa347/xsa347-4.14-1.patch 1bc6018c3685727ba4035bf0b5cea95940a1b9c4746fa9bddfd41507482d68a1 xsa347/xsa347-4.14-2.patch f1bd8eba268300f564837ac37fe43b774ace885c9cbf8fcacae457128730bc80 xsa347/xsa347-4.14-3.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 mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because removal of pass-through devices or their replacement by emulated devices is a guest visible configuration change, which may lead to re-discovery of the issue. Deployment of this mitigation is permitted only AFTER the embargo ends. 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 ========================================================= + 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 + =========================================================