-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2020-15566 / XSA-317 version 3 Incorrect error handling in event channel port allocation UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= The allocation of an event channel port may fail for multiple reasons: 1) Port is already in use 2) The memory allocation failed 3) The port we try to allocate is higher than what is supported by the ABI (e.g 2L or FIFO) used by the guest or the limit set by an administrator ('max_event_channels' in xl cfg). Due to the missing error checks, only 1) will be considered as an error. All the other cases will provide a "valid" port and will result to a crash when trying to access the event channel. IMPACT ====== When the administrator configured a guest to allow more than 1023 event channels, that guest may be able to crash the host. When Xen is out-of-memory, allocation of new event channels will result in crashing the host rather than reporting an error. VULNERABLE SYSTEMS ================== Xen versions 4.10 and later are affected. (The special Xen 4.8 "Comet" branch for XSA-254 contains changes similar to those which led to this vulnerability; so it is likely to be affected, but - like mainline Xen 4.8 - that branch is longer security-supported.) Older Xen versions are unaffected. All architectures are affected. The default configuration, when guests are created with xl/libxl, is not vulnerable, because of the default event channel limit (see Mitigation, below). MITIGATION ========== The problem can be avoided by reducing the number of event channels available to the guest no more than 1023. For example, setting "max_event_channels=1023" in the xl domain configuration, or deleting any existing setting (since 1023 is the default for xl/libxl). For ARM systems, any limit no more than 4095 is safe. For 64-bit x86 PV guests, any limit no more than 4095 is likewise safe if the host configuration prevents the guest administrator from substituting and running a 32-bit kernel (and thereby putting the guest into 32-bit PV mode). CREDITS ======= This issue was discovered by 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. xsa317.patch Xen 4.10 - xen-unstable $ sha256sum xsa317* 11e77dd8644cee40cee609d02e27d70655f3999005cae8c24fb2801980ebb4f2 xsa317.meta 17908035e2da07f6070fa8de345db68c96ed9bd78f8b114e43ba0194c1be3f15 xsa317.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the *patch* 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). And: deployment of the event channel limit reduction 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 such a change can be visible to the guest, so it would leak the preconditions for the vulnerability and maybe lead to rediscovery. Deployment of this, or similar mitigations, 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 -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl8EZ/gMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZQUwIAK8W8bZ0xml2bzAu4vsXi8QqhDX4VrpkgADYZS+M BD8hpllQ+O/CiM5ZMECj7zaWYTt7+VrGrqK4jtf2REBs/sOWcO+k7KdEury4XCKf jIG4CzCBHC46RVEKftiqQNTX2ebVBDwoj+1fGeIvm7OhcZ7f6KdhYPHvE2bU8D45 ghr2jw33HZHoG7IsPQvJn8u6wqd6l+7h0BxhgzO5U8pI+w3ZXRM4XAno+ERzs8LO N5ffv8UeaMIpkHoYEdsKOK/ItjhoCASoWTFvbE90u7f2WbimFnBG3oCPEVPt89kv Y/o0+0jBk+WjXbPChMmMu5WuQuKVFDelMXLLE6mjfhGAvnI= =vEgE -----END PGP SIGNATURE-----