==================================================================== CERT-Renater Note d'Information No. 2021/VULN108 _____________________________________________________________________ DATE : 19/02/2021 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-361.html https://xenbits.xen.org/xsa/advisory-362.html https://xenbits.xen.org/xsa/advisory-363.html https://xenbits.xen.org/xsa/advisory-364.html https://xenbits.xen.org/xsa/advisory-365.html https://xenbits.xen.org/xsa/advisory-366.html _____________________________________________________________________ Xen Security Advisory CVE-2021-26932 / XSA-361 version 4 Linux: grant mapping error handling issues UPDATES IN VERSION 4 ==================== Public release. ISSUE DESCRIPTION ================= Grant mapping operations often occur in batch hypercalls, where a number of operations are done in a single hypercall, the success or failure of each one reported to the backend driver, and the backend driver then loops over the results, performing follow-up actions based on the success or failure of each operation. Unfortunately, when running in PV mode, the Linux backend drivers mishandle this: Some errors are ignored, effectively implying their success from the success of related batch elements. In other cases, errors resulting from one batch element lead to further batch elements not being inspected, and hence successful ones to not be possible to properly unmap upon error recovery. IMPACT ====== A malicious or buggy frontend driver may be able to crash the corresponding backend driver, causing a denial of service potentially affecting the entire domain running the backend driver. A malicious or buggy frontend driver may be able to cause resource leaks in the domain running the corresponding backend driver, leading to a denial of service. VULNERABLE SYSTEMS ================== All Linux versions back to at least 3.2 are vulnerable, when running in PV mode on x86 or when running on Arm. On x86, only systems with Linux backends running in PV mode are vulnerable. Linux backends run in HVM / PVH modes are not vulnerable. MITIGATION ========== On x86, running the backends in HVM or PVH domains will avoid the vulnerability. For protocols where other, e.g. non-kernel-based backends are available, reconfiguring guests to use alternative (e.g. qemu-based) backends may allow to avoid the vulnerability as long as these backends don't rely on similar functionality provided by the xen-gntdev (/dev/gntdev) driver. In all other cases there is no known mitigation. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the attached patches resolves this issue. xsa361-linux-1.patch Linux 5.11-rc - 3.19 xsa361-linux-2.patch Linux 5.11-rc - 3.15 xsa361-linux-3.patch Linux 5.11-rc - 4.19 xsa361-linux-4.patch Linux 5.11-rc - 4.19 xsa361-linux-5.patch Linux 5.11-rc - 4.4 $ sha256sum xsa361* bb00ab6319b4fc536566af50c73e064f10f8b99eaa6b0f0b35a8d174c285a905 xsa361-linux-1.patch 73b6a54aa3773ce11f0de6b9aa1d80dd7f4c297dc71924b1a3886bc3b99ac859 xsa361-linux-2.patch 8e554cfab8cdb4fe1b74601a9432ea4c570f74a952ad757f9294ba1666cbeaea xsa361-linux-3.patch 8c290895d10fc148f99e2a6587811b3037f29c3a0201d69d448ff520cea6f96d xsa361-linux-4.patch 231ae3e1b9bec1b75dbbbee4b5acff620ef7ac2853332aa7b3c4957c6ca7f341 xsa361-linux-5.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. Deployment of the mitigation to switch to HVM / PVH backend domains is also permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER, deployment of the non-kernel-based backends mitigation 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 may be 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-2021-26931 / XSA-362 version 3 Linux: backends treating grant mapping errors as bugs UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= Block, net, and SCSI backends consider certain errors a plain bug, deliberately causing a kernel crash. For errors potentially being at least under the influence of guests, like out of memory conditions, it isn't correct to assume so. Memory allocations potentially causing such crashes occur only when Linux is running in PV mode, though. IMPACT ====== A malicious or buggy frontend driver may be able to crash the corresponding backend driver, potentially affecting the entire domain running the backend driver. VULNERABLE SYSTEMS ================== Linux versions from at least 2.6.39 onwards are vulnerable, when run in PV mode. Earlier versions differ significantly in behavior and may therefore instead surface other issues under the same conditions. Linux run in HVM / PVH modes is not vulnerable. MITIGATION ========== For Linux, running the backends in HVM or PVH domains will avoid the vulnerability. For protocols where non-Linux-kernel based backends are available, reconfiguring guests to use alternative (e.g. qemu-based) backends may allow to avoid the vulnerability. In all other cases there is no known mitigation. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate attached patches resolves this issue. Applying the attached patches resolves this issue. xsa362-linux-1.patch Linux 5.11-rc - 5.10 xsa362-linux-2.patch Linux 5.11-rc - 3.16 xsa362-linux-3.patch Linux 5.11-rc - 4.1 $ sha256sum xsa362* d64334807f16ff9909503b3cc9b8b93fd42d2c36e1fb0e508b89a765a53071a8 xsa362-linux-1.patch b6d02952e7fbede55b868cb2dc4d8853284996883dc72518a0cd5b14d6c7fdd4 xsa362-linux-2.patch 0a2661380d8f786fefe12e5a8b1528d4a79f1ad058c26b417c52449a7e16a302 xsa362-linux-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. Deployment of the mitigation to switch to HVM / PVH backend domains is also permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER, deployment of the non-kernel-based backends mitigation 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 may be 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-2021-26934 / XSA-363 version 3 Linux: display frontend "be-alloc" mode is unsupported UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= The backend allocation mode of Linux'es drm_xen_front drivers was not meant to be a supported configuration, but this wasn't stated accordingly in its support status entry. IMPACT ====== Use of the feature may have unknown effects. VULNERABLE SYSTEMS ================== Linux versions from 4.18 onwards are affected. Earlier Linux versions do not provide the affected driver. MITIGATION ========== Not using the driver or its backend allocation mode will avoid the vulnerability. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the attached patch documents the situation. The patch does not fix any security issues. xsa363.patch xen-unstable $ sha256sum xsa363* cf2f2eff446aec625b19d9d01301ec66098b58b792d74012235f10c62a21bb68 xsa363.patch $ _____________________________________________________________________ Xen Security Advisory CVE-2021-26933 / XSA-364 version 3 arm: The cache may not be cleaned for newly allocated scrubbed pages UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= On Arm, a guest is allowed to control whether memory access bypass the cache. This means that Xen needs to ensure that all writes (such as the ones during scrubbing) have reached memory before handing over the page to a guest. Unfortunately the operation to clean the cache happens before checking if the page was scrubbed. Therefore there is no guarantee when all the writes will reach the memory. IMPACT ====== A malicious guest may be able to read sensitive data from memory that previously belonged to another guest. VULNERABLE SYSTEMS ================== Xen version 4.9 onwards are vulnerable. Only Arm systems are vulnerable. MITIGATION ========== There is no known mitigation. 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. xsa364.patch xen-unstable - 4.11 $ sha256sum xsa364* c9dcb3052bb6ca4001e02b3ad889c70b4eebf1931bef83dfb7de86452851f3c8 xsa364.meta dc313c70bb07b4096bbc4612cbbc180589923277411dede2fda37f04ecc846d6 xsa364.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-2021-26930 / XSA-365 version 3 Linux: error handling issues in blkback's grant mapping UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= To service requests, the driver maps grant references provided by the frontend. In this process, errors may be encountered. In one case an error encountered earlier might be discarded by later processing, resulting in the caller assuming successful mapping, and hence subsequent operations trying to access space that wasn't mapped. In another case internal state would be insufficiently updated, preventing safe recovery from the error. IMPACT ====== A malicious or buggy frontend driver may be able to crash the corresponding backend driver, potentially affecting the entire domain running the backend driver. In configurations without driver domains or similar disaggregation, that is a host-wide denial of sevice. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS ================== Linux versions from at least 3.11 onwards are vulnerable. MITIGATION ========== Reconfiguring guests to use alternative (e.g. qemu-based) backends may avoid the vulnerability. CREDITS ======= This issue was discovered by Olivier Benjamin, Norbert Manthey, Martin Mazein, and Jan H. Schönherr, all from Amazon. RESOLUTION ========== Applying the attached patch resolves this issue. xsa365-linux.patch Linux 5.11-rc - 5.10 $ sha256sum xsa365* 7e45fcf3c70eb40debe9997a1773de7c4a2edcde5c23f76aeb5c1b6e3a34a654 xsa365-linux.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 non-kernel-based backends mitigation 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 may be 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 XSA-366 missed flush in XSA-321 backport ISSUE DESCRIPTION ================= An oversight was made when backporting XSA-320, leading entries in the IOMMU not being properly updated under certain circumstances. IMPACT ====== A malicious guest may be able to retain read/write DMA access to frames returned to Xen's free pool, and later reused for another purpose. Host crashes (leading to a Denial of Service) and privilege escalation cannot be ruled out. VULNERABLE SYSTEMS ================== Xen versions up to 4.11, from at least 3.2 onwards, are affected. Xen versions 4.12 and newer are not affected. Only x86 Intel systems are affected. x86 AMD as well as Arm systems are not affected. Only x86 HVM guests using hardware assisted paging (HAP), having a passed through PCI device assigned, and having page table sharing enabled can leverage the vulnerability. Note that page table sharing will be enabled (by default) only if Xen considers IOMMU and CPU large page size support compatible. MITIGATION ========== Suppressing the use of page table sharing will avoid the vulnerability (command line option "iommu=no-sharept"). Suppressing the use of large HAP pages will avoid the vulnerability (command line options "hap_2mb=no hap_1gb=no"). Not passing through PCI devices to HVM guests will avoid the vulnerability. CREDITS ======= This issue was reported as a bug by M. Vefa Bicakci, and recognized as a security issue by Roger Pau Monne of Citrix. 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. xsa366-4.11.patch Xen 4.11.x $ sha256sum xsa366* 3131c9487b9446655e2e21df4ccf1e003bec471881396d7b2b1a0939f5cbae96 xsa366.meta 8c8c18ca8425e6167535c3cf774ffeb9dcb4572e81c8d2ff4a73fefede2d4d94 xsa366-4.11.patch $ NOTE REGARDING LACK OF EMBARGO ============================== This was reported and debugged publicly, before the security implications were apparent. ========================================================= + 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 + =========================================================