Date: Wed, 08 Sep 2021 12:28:17 +0000 From: Xen.org security team <security@....org> To: xen-announce@...ts.xen.org, xen-devel@...ts.xen.org, xen-users@...ts.xen.org, oss-security@...ts.openwall.com CC: Xen.org security team <security-team-members@....org> Subject: Xen Security Advisory 384 v3 (CVE-2021-28701) - Another race in XENMAPSPACE_grant_table handling -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2021-28701 / XSA-384 version 3 Another race in XENMAPSPACE_grant_table handling UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= Guests are permitted access to certain Xen-owned pages of memory. The majority of such pages remain allocated / associated with a guest for its entire lifetime. Grant table v2 status pages, however, are de-allocated when a guest switches (back) from v2 to v1. Freeing such pages requires that the hypervisor enforce that no parallel request can result in the addition of a mapping of such a page to a guest. That enforcement was missing, allowing guests to retain access to pages that were freed and perhaps re-used for other purposes. Unfortunately, when XSA-379 was being prepared, this similar issue was not noticed. IMPACT ====== A malicious guest may be able to elevate its privileges to that of the host, cause host or guest Denial of Service (DoS), or cause information leaks. VULNERABLE SYSTEMS ================== All Xen versions from 4.0 onwards are affected. Xen versions 3.4 and older are not affected. Only x86 HVM and PVH guests permitted to use grant table version 2 interfaces can leverage this vulnerability. x86 PV guests cannot leverage this vulnerability. On Arm, grant table v2 use is explicitly unsupported. MITIGATION ========== Running only PV guests will avoid this vulnerability. Suppressing use of grant table v2 interfaces for HVM or PVH guests will also avoid this vulnerability. NOTE REGARDING EMBARGO ====================== Please note that the public embargo time for this advisory is 2021-09-08, two weeks later than XSA-378,379,380,382,383. 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. xsa384.patch xen-unstable - Xen 4.15.x xsa384-4.14.patch Xen 4.14.x - 4.12.x xsa384-4.11.patch Xen 4.11.x $ sha256sum xsa384* 3bf555e8b2a37dec361b86c0b6a3f59af2e1a24e3457ed92e0cfeaa662f1663a xsa384.patch 435b431dc77d255031832dc265a8d5aa2f13f3b1a7de497b62ac2df5ad61da90 xsa384-4.11.patch f98ec4c25fb122de6353eb7d9f5678dd09982f887bf201d6f178e9b647618c9a xsa384-4.14.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or PV-guest-only 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. HOWEVER, distribution of updated software is prohibited (except to other members of the predisclosure list). ADDITIONALLY, deployment of the grant table v2 disabling mitigation described above *is* now (following the public release of XSA-379) permitted during the embargo on public-facing systems with untrusted guest users and administrators. This is because (although such a configuration change is recognizable by the affected guests) it is a mitigation recommended in XSA-379, so such a change would not reveal the existence of a further problem. 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----- iQE/BAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmE4rD4MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ8S8H+ITq1u5AaK+N1wgsgztLJRh1cjFTDaLZdI0mypwV +wPhNdw1FFH19wYDZhOJIzv3h5352YVUYs8P6HvhFWrsUaq5n4cz17wxUHch74r3 MUUU9WUdTffQrAAOSSK65yWTUewv/FglEWP55YFBDPqBJHpVWt2MMidmP6My6azK GZAHSWU7+qNXbs4/OM+dQJyUJm6yZtAltVtVmiJdJ5bSZyqe+82zRMnS39jlkZEh VwFnw6rdlPcYO/fNYi25bQSlXbFeruSJYK+omrrFsyd65Z4D5LyZc5CQkfRJgEt6 vMDsQR+5hrE/KXKr2mfyTx6nh0RdR8kcI2Wh017BYuLqhA== =AEo5 -----END PGP SIGNATURE----- Download attachment "xsa384.patch" of type "application/octet-stream" (2852 bytes) Download attachment "xsa384-4.11.patch" of type "application/octet-stream" (2870 bytes) Download attachment "xsa384-4.14.patch" of type "application/octet-stream" (2827 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.