==================================================================== CERT-Renater Note d'Information No. 2020/VULN683 _____________________________________________________________________ DATE : 15/12/2020 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-348.html https://xenbits.xen.org/xsa/advisory-349.html https://xenbits.xen.org/xsa/advisory-350.html https://xenbits.xen.org/xsa/advisory-352.html https://xenbits.xen.org/xsa/advisory-353.html https://xenbits.xen.org/xsa/advisory-354.html https://xenbits.xen.org/xsa/advisory-355.html https://xenbits.xen.org/xsa/advisory-356.html https://xenbits.xen.org/xsa/advisory-358.html https://xenbits.xen.org/xsa/advisory-359.html _____________________________________________________________________ Xen Security Advisory CVE-2020-29566 / XSA-348 version 3 undue recursion in x86 HVM context switch code UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= When they require assistance from the device model, x86 HVM guests must be temporarily de-scheduled. The device model will signal Xen when it has completed its operation, via an event channel, so that the relevant vCPU is rescheduled. If the device model were to signal Xen without having actually completed the operation, the de-schedule / re-schedule cycle would repeat. If, in addition, Xen is resignalled very quickly, the re-schedule may occur before the de-schedule was fully complete, triggering a shortcut. This potentially repeating process uses ordinary recursive function calls, so could result a stack overflow. IMPACT ====== A malicious or buggy stubdomain serving a HVM guest can cause Xen to crash, resulting in a Denial of Service (DoS) to the entire host. VULNERABLE SYSTEMS ================== All Xen versions are vulnerable. Only x86 systems are affected. Arm systems are not affected. Only x86 stubdomains serving HVM guests can exploit the vulnerability. MITIGATION ========== Running only PV or PVH guests will avoid the vulnerability. (Switching from a device model stub domain to a dom0 device model does NOT mitigate this vulnerability. Rather, it simply recategorises the vulnerability to hostile management code, regarding it "as designed"; thus it merely reclassifies these issues as "not a bug". The security of a Xen system using stub domains is still better than with a qemu-dm running as a dom0 process. Users and vendors of stub qemu dm systems should not change their configuration to use a dom0 qemu process.) CREDITS ======= This issue was discovered by Julien Grall of Amazon. RESOLUTION ========== Applying the appropriate (set of) attached patch(es) 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. xsa348-?.patch xen-unstable - Xen 4.14.x xsa348-4.13-?.patch Xen 4.13.x xsa348-4.12.patch Xen 4.12.x xsa348-4.11.patch Xen 4.11.x xsa348-4.10.patch Xen 4.10.x $ sha256sum xsa348* f9606145cdbd3caacf6be7e5bcb62fc7d2c0b76572c1be26db608c5eac57ead0 xsa348.meta b619dac8453daa9f85526dec67ed67d999d182ccbc39b91be122b3365a0b5cb9 xsa348-1.patch 01b11ea3be160704c992187ad727ac1f03841cc452bbe2c142b53fddfa2da844 xsa348-2.patch 2c54474da9680625717e5a61b2a3a5ac23acad6f7bc0fcb306fe181fd0a38f1d xsa348-3.patch e2f4cbec1a763f045e827ececf13d06dedcc7cc49b42136160c8d986778529ae xsa348-4.10.patch 15d4f5fb894a45027f4a17a557d4fdb0a390575ab2c2d3aa2b265d3c6239c765 xsa348-4.11.patch 58b1a771dc720b1efb205a9d1baf46aea0205d4c65310e693dd2cfe7834cd8b9 xsa348-4.12.patch 1d181edd11f2437ff9298f9b5e81d75f5e5db8a79a8ce2c5aed0d75882473a0b xsa348-4.13-1.patch b68d3dfa2003a7444c165ab3639886b9b502c06cdfd4f43bea747d8fb14dc7cd xsa348-4.13-2.patch 67ecb0819041bf0b20a1af42970af72a15842571beb13cd0d740b0600e1aa2fd xsa348-4.13-3.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-2020-29568 / XSA-349 version 3 Frontends can trigger OOM in Backends by update a watched path UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= Some OSes (such as Linux, FreeBSD, NetBSD) are processing watch events using a single thread. If the events are received faster than the thread is able to handle, they will get queued. As the queue is unbound, a guest may be able to trigger a OOM in the backend. IMPACT ====== A malicious guest can trigger an OOM in backends. VULNERABLE SYSTEMS ================== All systems with a FreeBSD, Linux, NetBSD dom0 are vulnerable. All version of those OSes are vulnerable. MITIGATION ========== There is no known mitigation. CREDITS ======= This issue was discovered by Michael Kurth and Pawel Wieczorkiewicz of Amazon. RESOLUTION ========== Applying the appropriate attached patch resolves this issue for Linux. Fixes for FreeBSD and NetBSD will be handled through their own security process. Fixes for FreeBSD and NetBSD will be handled through their own security process. xsa349/xsa349-linux-?.patch Linux $ sha256sum xsa349*/* 76f69574553137af8c9c7aecca3025d135b49c4a5316cc541e9e355576a21599 xsa349/xsa349-linux-1.patch 3ce2e1a88321993a3698b4608d2332fb5d43e0d82de73bc9f1700202782eba30 xsa349/xsa349-linux-2.patch 4bbaf62ed5e3442b310f80344b9d3ccd37f0a07827ed41907b44228130a610da xsa349/xsa349-linux-3.patch a7648214cea5d0340a29552df224230cf214d698fe2d7a8798f57444225afe32 xsa349/xsa349-linux-4.patch ac32d02129821ed7db1b71c39b2c708399c0af809eefdb5bf0709f00736e7959 xsa349/xsa349-linux-5.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-2020-29569 / XSA-350 version 4 Use after free triggered by block frontend in Linux blkback UPDATES IN VERSION 4 ==================== Public release. ISSUE DESCRIPTION ================= The Linux kernel PV block backend expects the kernel thread handler to reset ring->xenblkd to NULL when stopped. However, the handler may not have time to run if the frontend quickly toggle between the states connect and disconnect. As a consequence, the block backend may re-use a pointer after it was freed. IMPACT ====== A misbehaving guest can trigger a dom0 crash by continuously connecting / disconnecting a block frontend. Privileged escalation and information leak cannot be ruled out. VULNERABLE SYSTEMS ================== Systems using Linux blkback are vulnerable. This includes most systems with a Linux dom0, or Linux driver domains. Linux versions containing a24fa22ce22a ("xen/blkback: don't use xen_blkif_get() in xen-blkback kthread"), or its backports, are vulnerable. This includes all current linux-stable branches back to at least linux-stable/linux-4.4.y. When the Xen PV block backend is provided by userspace (eg qemu), that backend is not vulnerable. So configurations where the xl.cfg domain configuration file specifies all disks with backendtype="qdisk" are not vulnerable. The Linux blkback only supports raw format images, so when all disks have a format than format="raw", the system is not vulnerable. MITIGATION ========== Switching the disk backend to qemu with backendtype="qdisk" will avoid the vulnerability. This mitigation is not always available, depending on the other aspects of the configuration. CREDITS ======= This issue was discovered by Olivier Benjamin and Pawel Wieczorkiewicz of Amazon. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa350-linux.patch Linux $ sha256sum xsa350* 46e8141bcfd21629043df0af4d237d6c264b27c1137fc84d4a1127ace30926c4 xsa350-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. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Deployment of the mitigation to change the block backend 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 this is a guest-visible change, which will indicate that it is the block backend which has a vulnerability. Deployment is permitted only AFTER the embargo ends. 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-2020-28368 / XSA-351 version 2 Information leak via power sidechannel UPDATES IN VERSION 2 ==================== CVE assigned. ISSUE DESCRIPTION ================= Researchers have demonstrated using software power/energy monitoring interfaces to create covert channels, and infer the operations/data used by other contexts within the system. Access to these interfaces should be restricted to privileged software, but it was found that Xen doesn't restrict access suitably, and the interfaces are accessible to all guests. For more information, see: https://platypusattack.com https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00389.html IMPACT ====== An unprivileged guest administrator can sample platform power/energy data. This may be used to infer the operations/data used by other contexts within the system. The research demonstrates using this sidechannel to leak the AES keys used elsewhere in the system. VULNERABLE SYSTEMS ================== Power/energy monitoring interfaces are platform and architecture specific. Consult your hardware vendor to ascertain what power feedback interfaces are available. For ARM systems, all versions of Xen are vulnerable. The fix restricts access to the AMU (Activity Monitors Unit) interface, introduced in Armv8.4. For x86 systems, Xen 4.14 and earlier are vulnerable - master is not vulnerable, as these issues have been addressed in a more general fashion. The x86 fixes restrict access to: * Intel RAPL interface, introduced in SandyBridge CPUs. * Intel platform energy interface. * Intel perf_ctl interface, introduced in Pentium 4 CPUs and also implemented by other vendors. * AMD RAPL interface, introduced in Ryzen/EPYC CPUs. * AMD compute unit energy interface, present in Fam15/16 CPUs. MITIGATION ========== There are no mitigations available. 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. xsa351-arm.patch Xen unstable - 4.10.x [ARM] xsa351-x86-4.14-?.patch Xen 4.14.x [x86] xsa351-x86-4.13-?.patch Xen 4.13.x [x86] xsa351-x86-4.12-?.patch Xen 4.12.x [x86] xsa351-x86-4.11-?.patch Xen 4.11.x - 4.10.x [x86] $ sha256sum xsa351* cad287981a870f13484834fa2364ffee68178517e906f55d2889304a4a9eae06 xsa351.meta 70ebd0e93af240af2680374dcfd8ff4a5dd3eefccf670f1cb9b546d763d6a554 xsa351-arm.patch 49b52a1366912a29e184e3014a9f1f579e8a0dd8a36f01d38d995d2c8ed81928 xsa351-arm-4.11.patch 2e7b7c2b98625d70c8b10047a9f668372f3ccede167344dedb712312606acbca xsa351-x86-4.11-1.patch ab9e2cb7d5e3e0c3a916f006c697495f4f01146e09df60ece59ce0a8f7aa5ed0 xsa351-x86-4.11-2.patch bb68f6e6905bc1566156cafab058cbaf02a17c197385c33a83b7f73885913c1c xsa351-x86-4.12-1.patch 53f464269f59498f8a9a614f10a47cfb1d81c666f0d684346e28005015de962c xsa351-x86-4.12-2.patch 67a29d66230faafd9a8047ac80ec18130b5659e80a38c3a412cb2be6d3288a8f xsa351-x86-4.13-1.patch f7d8717dec33ee7484b36490402d113f1e7e168e7541bcf193fef620df299f08 xsa351-x86-4.13-2.patch 7d4fbe11a766226d7f1b93c5bf34664d8855deee09d1feebc76f11e49f2aa9c9 xsa351-x86-4.14-1.patch 41df825deafe3ef28e8594ec956033689af69f84a4a6dd92f97d1071e925203d xsa351-x86-4.14-2.patch $ NOTE REGARDING LACK OF EMBARGO ============================== Despite an attempt to organise predisclosure, the discoverers ultimately did not authorise a predisclosure. _____________________________________________________________________ Xen Security Advisory CVE-2020-29486 / XSA-352 version 3 oxenstored: node ownership can be changed by unprivileged clients UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= Nodes in xenstore have an ownership. In oxenstored, a owner could give a node away. But node ownership has quota implications. Any guest can run another guest out of quota, or create an unbounded number of nodes owned by dom0, thus running xenstored out of memory IMPACT ====== A malicious guest administrator can cause denial of service, against a specific guest or against the whole host. VULNERABLE SYSTEMS ================== All systems using oxenstored are vulnerable. Building and using oxenstored is the default in the upstream Xen distribution, if the Ocaml compiler is available. Systems using C xenstored are not vulnerable. MITIGATION ========== There are no mitigations. Changing to use of C xenstored would avoid this vulnerability. However, given the other vulnerabilities in both versions of xenstored being reported at this time, changing xenstored implementation is not a recommended approach to mitigation of individual issues. CREDITS ======= This issue was discovered by Edwin Török 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. xsa352.patch xen-unstable - 4.10 $ sha256sum xsa352* a3b2b2bd4c6b49c472df23f88fb9a5e204d2ba3cd0c3901f8ed057566ef98c85 xsa352.meta 6f9798e20282d4e06f0a8a1abd0d147649e20b33c21559d5a1ea0b1a73a2a4e4 xsa352.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-2020-29479 / XSA-353 version 4 oxenstored: permissions not checked on root node UPDATES IN VERSION 4 ==================== Public release. ISSUE DESCRIPTION ================= In the Ocaml xenstored implementation, the internal representation of the tree has special cases for the root node, because this node has no parent. Unfortunately, permissions were not checked for certain operations on the root node. Unprivileged guests can get and modify permissions, list, and delete the root node. Deleting the whole xenstore tree is a hostwide denial of service. Depending on the circumstances, the vulnerability can also be leveraged into an ability to gain write access to any part of xenstore. IMPACT ====== A guest administrator can deny service to the whole system simply by deleting the whole of xenstore. Additionally, depending on other software in use, privilege escalation may be possible. With the default "xl" toolstack, a guest administrator can escalate their privilege to that of the host. VULNERABLE SYSTEMS ================== All systems using oxenstored are vulnerable. Building and using oxenstored is the default in the upstream Xen distribution, if the Ocaml compiler is available. The impact depends on the toolstack and other management software in use. Systems using libxl (for example, via "xl" or libvirt) are vulnerable to privilege escalation. Systems using C xenstored are not vulnerable, no matter what toolstack or management software is in use. MITIGATION ========== There are no mitigations. Changing to use of C xenstored would avoid this vulnerability. However, given the other vulnerabilities in both versions of xenstored being reported at this time, changing xenstored implementation is not a recommended approach to mitigation of individual issues. CREDITS ======= This issue was discovered by Edwin Török 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. Note that the Ocaml patches for XSA-115 depend on this patch. xsa353.patch xen-unstable - 4.10 $ sha256sum xsa353* 48fa1f414773ab1a4135fe62aaae25c7c543efe5a4c5dba71db9e497fa9f3362 xsa353.meta e14922bf6b2095c1b17849b130e999726a1a31e29be1374e0cd3f9a8fa59fd3d xsa353.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-2020-29487 / XSA-354 version 4 XAPI: guest-triggered excessive memory usage UPDATES IN VERSION 4 ==================== Public release. ISSUE DESCRIPTION ================= Certain xenstore keys provide feedback from the guest, and are therefore watched by toolstack. Specifically, keys are watched by xenopsd, and data are forward via RPC through message-switch to xapi. The watching logic in xenopsd sends one RPC update containing all data, any time any single xenstore key is updated, and therefore has O(N^2) time complexity. Furthermore, message-switch retains recent (currently 128) RPC messages for diagnostic purposes, yielding O(M*N) space complexity. The quantity of memory a single guest can monopolise is bounded by xenstored quota, but the quota is fairly large. It is believed to be in excess of 1G per malicious guest. In practice this manifests as a host denial of service, either through message-switch thrashing against swap, or OOM'ing entirely, depending on dom0's configuration. This series introduces quotas in xenopsd to limit the quantity of keys which result in RPC traffic. IMPACT ====== A buggy or malicious guest can cause unreasonable memory usage in dom0, resulting in a host denial of service. VULNERABLE SYSTEMS ================== All versions of XAPI are vulnerable. Systems which are not using the XAPI toolstack are not vulnerable. MITIGATION ========== There are no mitigations available. CREDITS ======= This issue was discovered by Edwin Török 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. xsa354-*.patch xenopsd master $ sha256sum xsa354* 66d29c38ce4fa6c77a4853a0f0345f3bf1fcbe11703090e1dbfa83257564de42 xsa354-1-ls_lR-factor-out-dir-concatenation.patch 0686465119b4442d839d59c66c41d02ce6b4cfa9c82234e0aefcaffbb7985ee4 xsa354-2-ls_lR-refactor-use-fold.patch fb60812f1230526f9c3be77d4f0c8c08903b21aa5c449056dc16b1181720b3cb xsa354-3-ls_lR-separate-recursion-into-separate-funct.patch 41f221007abd89c8d24dacb7b0ff96109427c1c84eae75b7245bb287a0938d81 xsa354-4-ls_lR-add-quota.patch fcd4abddf18bc5b875ec28213f3138f1de395e91076b5b1a828353bc8b19d8ed xsa354-5-ls_lR-limit-depth.patch 1ff82640a446407492904b50b05fc903a70d570620cd20a21493c9240b38f8be xsa354-6-exclude-attr-os-hotfixes-from-ls_lR.patch b1b2f96b93d41201ddfdb093660f06f8bce5461a715cfeb7110f0194b74c93cb xsa354-7-read-important-xenstore-entries-first.patch 6908e957c299fe57dcd5c5c93162d135326221f1e66ac4b43b771ebd63bae35d xsa354-8-refactor-attr-os-hotfixes-exclusion.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-355 version 2 stack corruption from XSA-346 change UPDATES IN VERSION 2 ==================== Added metadata file. Public release. ISSUE DESCRIPTION ================= One of the two changes for XSA-346 introduced an on-stack array. The check for guarding against overrunning this array was off by one, allowing for corruption of the first stack slot immediately following this array. IMPACT ====== A malicious or buggy HVM or PVH guest can cause Xen to crash, resulting in a Denial of Service (DoS) to the entire host. Privilege escalation as well as information leaks cannot be excluded. VULNERABLE SYSTEMS ================== All Xen versions which have the patches for XSA-346 applied are vulnerable. Only x86 HVM and PVH guests can leverage the vulnerability. Arm guests and x86 PV guests cannot leverage the vulnerability. Only x86 HVM and PVH 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 Jan Beulich of SUSE. RESOLUTION ========== Applying the 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. xsa355.patch xen-unstable - Xen 4.10.x $ sha256sum xsa355* a93bfc376897e7cffd095d395f1a66476adb9503d7d80a59b7861e64c2675323 xsa355.meta dae633c11cf2eff3e304737265e18ab09213e8e4640458080a944ae7a40819a4 xsa355.patch $ NOTE CONCERNING SHORT EMBARGO ============================= This issue is likely to be re-discovered as the changes for XSA-346 are deployed more widely, since the issue is also triggerable without any malice or bugginess. 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-2020-29567 / XSA-356 version 3 infinite loop when cleaning up IRQ vectors UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= When moving IRQs between CPUs to distribute the load of IRQ handling, IRQ vectors are dynamically allocated and de-allocated on the relevant CPUs. De-allocation has to happen when certain constraints are met. If these conditions are not met when first checked, the checking CPU may send an interrupt to itself, in the expectation that this IRQ will be delivered only after the condition preventing the cleanup has cleared. For two specific IRQ vectors this expectation was violated, resulting in a continuous stream of self-interrupts, which renders the CPU effectively unusable. IMPACT ====== A domain with a passed through PCI device can cause lockup of a physical CPU, resulting in a Denial of Service (DoS) to the entire host. VULNERABLE SYSTEMS ================== Only Xen 4.14 is affected. Xen versions 4.13 and older are not affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only guests with physical PCI devices passed through to them can exploit the vulnerability. MITIGATION ========== There is no known mitigation. CREDITS ======= This issue was discovered by Roger Pau Monné of Citrix. RESOLUTION ========== Applying the 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. xsa356.patch xen-unstable - Xen 4.14.x $ sha256sum xsa356* 77316e3b86e2482ee9741db7484d323a399028762af1c88734f8c83e78069fb3 xsa356.meta 21c217e41549bf74d5fcc26f1d23b6d902c5c72de5e2c8490842aea9f999b036 xsa356.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-2020-29570 / XSA-358 version 4 FIFO event channels control block related ordering UPDATES IN VERSION 4 ==================== Public release. ISSUE DESCRIPTION ================= Recording of the per-vCPU control block mapping maintained by Xen and that of pointers into the control block is reversed. The consumer assumes, seeing the former initialized, that the latter are also ready for use. IMPACT ====== Malicious or buggy guest kernels can mount a Denial of Service (DoS) attack affecting the entire system. VULNERABLE SYSTEMS ================== All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not 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. xsa358.patch xen-unstable - 4.10 $ sha256sum xsa358* c8392659f71ea31574f9f82ab80a37e1359e8b8178d7b060167500bfb134eecc xsa358.meta ee719ff8dbf30794ddac1464267cb47c1aac7e39da32d82263f4aebc1a9b509b xsa358.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-2020-29571 / XSA-359 version 3 FIFO event channels control structure ordering UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= A bounds check common to most operation time functions specific to FIFO event channels depends on the CPU observing consistent state. While the producer side uses appropriately ordered writes, the consumer side isn't protected against re-ordered reads, and may hence end up de-referencing a NULL pointer. IMPACT ====== Malicious or buggy guest kernels can mount a Denial of Service (DoS) attack affecting the entire system. VULNERABLE SYSTEMS ================== All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only Arm systems may be vulnerable. Whether a system is vulnerable will depend on the specific CPU. x86 systems are not vulnerable. MITIGATION ========== There is no known mitigation. CREDITS ======= This issue was discovered by Julien Grall of Amazon. RESOLUTION ========== Applying the 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. xsa359.patch xen-unstable - 4.10 $ sha256sum xsa359* cb009ad77d1a3d8044431b2af568dd9dffefe07fc9f537fb6b53c2ec57aa77b7 xsa359.meta 3126d9304b68be84a89c42c223227c8f96ecbb96a0385a7e1bdc65ae5e0f344f xsa359.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 + =========================================================