===================================================================== CERT-Renater Note d'Information No. 2021/VULN420 _____________________________________________________________________ DATE : 25/08/2021 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-379.html https://xenbits.xen.org/xsa/advisory-378.html https://xenbits.xen.org/xsa/advisory-380.html https://xenbits.xen.org/xsa/advisory-382.html https://xenbits.xen.org/xsa/advisory-383.html _____________________________________________________________________ Xen Security Advisory CVE-2021-28697 / XSA-379 version 2 grant table v2 status pages may remain accessible after de-allocation UPDATES IN VERSION 2 ==================== Patches updated to fix a typo in a comment. Public release. ISSUE DESCRIPTION ================= Guest get 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, get de-allocated when a guest switched (back) from v2 to v1. The freeing of such pages requires that the hypervisor know where in the guest these pages were mapped. The hypervisor tracks only one use within guest space, but racing requests from the guest to insert mappings of these pages may result in any of them to become mapped in multiple locations. Upon switching back from v2 to v1, the guest would then retain access to a page that was freed and perhaps re-used for other purposes. 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. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. 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. xsa379.patch xen-unstable xsa379-4.15.patch Xen 4.15.x xsa379-4.14.patch Xen 4.14.x - 4.13.x xsa379-4.12.patch Xen 4.12.x - 4.11.x $ sha256sum xsa379* bdda4cb431301551336388ff7300a6ae95bb75af8fcae09cfb12c22a91d399d9 xsa379.meta 508dbfcac7420ec780df39402116bf7d3f497c4a9d883a369df7bf5340778e6c xsa379.patch 2a1db918f1fa387a97d7bcb525eaa928fd71a9967e6ced4e7ac6e39a79ab5b80 xsa379-4.12.patch c57b72078460f45a5e003db5c4c3669f27310420e04eb16e4413318dfee54fa1 xsa379-4.14.patch 3154869b12fcde70ce845df723aae4bbb2eb9576d90267c1be01eb6d3c5196e9 xsa379-4.15.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, deployment of the grant table v2 disabling 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 is 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-28694,CVE-2021-28695,CVE-2021-28696 / XSA-378 version 2 IOMMU page mapping issues on x86 UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= Both AMD and Intel allow ACPI tables to specify regions of memory which should be left untranslated, which typically means these addresses should pass the translation phase unaltered. While these are typically device specific ACPI properties, they can also be specified to apply to a range of devices, or even all devices. On all systems with such regions Xen failed to prevent guests from undoing/replacing such mappings (CVE-2021-28694). On AMD systems, where a discontinuous range is specified by firmware, the supposedly-excluded middle range will also be identity-mapped (CVE-2021-28695). Further, on AMD systems, upon de-assigment of a physical device from a guest, the identity mappings would be left in place, allowing a guest continued access to ranges of memory which it shouldn't have access to anymore (CVE-2021-28696). IMPACT ====== The precise impact is system specific, but can - on affected systems - be any or all of privilege escalation, denial of service, or information leaks. VULNERABLE SYSTEMS ================== The vulnerability is only exploitable by guests granted access to physical devices (ie, via PCI passthrough). All versions of Xen are affected. Only x86 systems with IOMMUs and with firmware specifying memory regions to be identity mapped are affected. Other x86 systems are not affected. Whether a particular system whose ACPI tables declare such memory region(s) is actually affected cannot be known without knowing when and/or how these regions are used. For example, if these regions were used only during system boot, there would not be any vulnerability. The necessary knowledge can only be obtained from, collectively, the hardware and firmware manufacturers. On Arm hardware IOMMU use is not security supported. Accordingly, we have not undertaken an analysis of these issues for Arm systems. MITIGATION ========== Not permitting untrusted guests access to phsyical devices will avoid the vulnerability. Likewise, limiting untrusted guest access to physical devices whose firmware-provided ACPI tables declare identity mappings, will avoid the vulnerability. (Provided that there are no identity mapped regions which are specified by the ACPI tables to apply globally.) Note that a system is still vulnerable if a guest was trusted, while it had such a device assigned, and then has the device removed in anticipation of the guest becoming untrusted (because of, for example, the insertion of an untrusted kernel module), CREDITS ======= This issue was discovered by 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. xsa378/xsa378-?.patch xen-unstable xsa378/xsa378-4.15-?.patch Xen 4.15.x xsa378/xsa378-4.14-?.patch Xen 4.14.x xsa378/xsa378-4.13-*.patch Xen 4.13.x xsa378/xsa378-4.12-*.patch Xen 4.12.x xsa378/xsa378-4.11-*.patch Xen 4.11.x $ sha256sum xsa378* xsa378*/* b3b49681468bd2be4b95fc1d3861493bbea63bac1c115a12ece76d0313b6a81c xsa378.meta 2560d4418e6b6d022b4e7fe1f84906ca13b3180537e746ee81cd3f97f0e86c35 xsa378/xsa378-1.patch 134b207c38f8d76bbc218220f1e61f82780e8166818ef51217716023cc27ce3c xsa378/xsa378-2.patch c166ef60e08a80440f79d92abe8488b123c8017e7633dbddacb95b20899f9b2b xsa378/xsa378-3.patch a2677e157724f57f65165f361a309c417d123ff009168f16d3a0e342b7a601eb xsa378/xsa378-4.11-0a.patch 832f52f420bb47784bdefd75edd1ca521658327aafb94b4f3586da522d0d19c1 xsa378/xsa378-4.11-0b.patch 9eb7c53892f01424eec6b788f879b36dd75a6f89b1c8b9c973237603525d6546 xsa378/xsa378-4.11-0c.patch 48021fb9a2c52d7939fd11bbba80c67a5a5b6cae2039b4b2a2c6203eb5841260 xsa378/xsa378-4.11-1.patch 4f3fd39aa328c1e397aa2a10b92e98cc341908a8834302a4fc0f230876dd3570 xsa378/xsa378-4.11-2.patch 6e2eeecd2ccc4029f80888263f44b80acf078d69aeffda4d6accd8b2d0899182 xsa378/xsa378-4.11-3.patch 194b27510c8765f1cf8abee57624a075ab26f4f889aa8c201e126643f570f55a xsa378/xsa378-4.11-4.patch e8f4eab0984a7db2ca0c6c9ac0fb9107e45ddd572a36454db4a1bdb8b9a8b0c6 xsa378/xsa378-4.11-5.patch 943c7556be47b1a0f2273cf5691fe70dc65e6cb50ff0477d1d61eb3f0ba87a97 xsa378/xsa378-4.11-6.patch 2eb572e1a55caa4aca31f74a3844135a204c4e023a6776d7adc4f4043663fb99 xsa378/xsa378-4.11-7.patch 7c24ba33461d3adcb195a6611df3e9c0501e9dcacf9b8811456450b291d23edf xsa378/xsa378-4.11-8.patch fe14ea6699df673b787f93ff821838f2280407674df0c8c06d40efe8320e8748 xsa378/xsa378-4.12-0a.patch 1ba10aef9ea99c4455a34e61792ca65ea6b2ece56f05cd0b4adc14600a7ae346 xsa378/xsa378-4.12-0b.patch 2c2dbc0c18b695c1d2c93e4137228f82b6d21d895c3165a9e29ddea3db78e36a xsa378/xsa378-4.12-0c.patch 48021fb9a2c52d7939fd11bbba80c67a5a5b6cae2039b4b2a2c6203eb5841260 xsa378/xsa378-4.12-1.patch f0d62506ccdf081d0efbb553e2d33f17a084272d21f43bf95d11fda2dcc8a3fa xsa378/xsa378-4.12-2.patch e266512b18fc30e5bd4884cd720aa81644d3ca3323b38fe1f77d06fa98dd515d xsa378/xsa378-4.12-3.patch 076f9955593a8ebdea5f24ed302b8a1004bbf50da4c8becf1f93764066b8981c xsa378/xsa378-4.12-4.patch 9639bc35636ffae4e2b6dd026387347960c1fb986cb2924a18314a72e6b6ec0a xsa378/xsa378-4.12-5.patch 32dd659aa365d9f8197d99b9334c22b33e9ce805e30376457df6e507f92282c8 xsa378/xsa378-4.12-6.patch 7eaae2fa968eb11e27277141456cc1bd657025aee738221c368e153535c7c0f4 xsa378/xsa378-4.12-7.patch 05982f43f35b580ff41f74b1280e469e0dd20176f184ec04a4874303c2aa3ad1 xsa378/xsa378-4.12-8.patch c6f551ef9903a343b47692b34a63c70165a2dbf74878a6be6511cdffd55a7e8c xsa378/xsa378-4.13-0a.patch 223cd63f7e1c39d862b8654da698455ded65ecb5abae0f57c330921522b7fdb4 xsa378/xsa378-4.13-0b.patch 5c33aa24f14e779dfe914e809cff11260083169a3adfb07a31ce11243d80b3ef xsa378/xsa378-4.13-0c.patch 1d55426ff6a41f0ef4cbd2c943edafff394157703bb0b6ae751564abf93b5ee7 xsa378/xsa378-4.13-1.patch 4d5e7d5e65cd28d6bc7d1a9f2ab24f09dfaef295c4199d5f2db00915dcaa174f xsa378/xsa378-4.13-2.patch 78df0bcb347f8bb45827f74b191aad36b6e907eb38c6d535035f2b2739645551 xsa378/xsa378-4.13-3.patch 237c33e0ae01a23db01721afb8e6a39101bfe081f8b75dbcff6b9fa9c9aaceda xsa378/xsa378-4.13-4.patch 7d2f3ae3881d28073be54a6dfb35f13004e4efee742952788430201d86307ecf xsa378/xsa378-4.13-5.patch 2ecd7580394667db0c41e4819025393e59ae24d6c97d54451c8e683585057367 xsa378/xsa378-4.13-6.patch 592a03d00e5d22d7a3c001681968dc469c70b3e57998b95877388e9528904ea2 xsa378/xsa378-4.13-7.patch 54e6a095f706c66dbbd74e39aa1d88031c9b537589e73ceb2925e2f0cc1854f0 xsa378/xsa378-4.13-8.patch 1d55426ff6a41f0ef4cbd2c943edafff394157703bb0b6ae751564abf93b5ee7 xsa378/xsa378-4.14-1.patch 86fbd88eb8a358575e42cf335c444b047ddb4d2f1c6a1bc6f9e57e6ac0041074 xsa378/xsa378-4.14-2.patch 0a23e5f93ff1bb55f003a56e0ef8c531384b164f0e840f5794acdb9ae3e91996 xsa378/xsa378-4.14-3.patch e2226f7ddae1d24dbee8cf19efa8d67ebf312f3d10641cb9aec21d68a3c8f818 xsa378/xsa378-4.14-4.patch f2cf8f7e4aa0460e606b5564adde366332ed323c4d5e3f957e64299ef1bc9baf xsa378/xsa378-4.14-5.patch 7811426975757e3bb8c6ab3161ba2354e1780b55b9e6be7928229d5f23bf79b6 xsa378/xsa378-4.14-6.patch 58147bd6c0ea4e08e84a17afc796be4bbe53e6fbc1d393f9fe3c6191fd33eba5 xsa378/xsa378-4.14-7.patch 682a011d807a7c284faf0ec9d2cf0aabaddbc658979dea2b9ccbc007b660f9c5 xsa378/xsa378-4.14-8.patch a00ada0cd673f0909cc7b462cb532dbd6fe17601e06bd84272f5ff1857ea4c73 xsa378/xsa378-4.15-1.patch d74cc325be1e47d61ba3b1400837af35d044bf1d25806aa98926ec262f80bddd xsa378/xsa378-4.15-2.patch 2ad685a04dbbdd2c81761b58146e70059b8a8a92b0c1176f36933510293ece5b xsa378/xsa378-4.15-3.patch 18de9facccd70ce49dd839e219fe71667c43110e474e5d7b56a503a5786fc7e0 xsa378/xsa378-4.15-4.patch 296558b27ba82176f6d06b721102c8ba7c7e6e99d29b29392ea82244e88df0b9 xsa378/xsa378-4.15-5.patch 5d7cc84c66daf0aceab9407fa72f2827024c847f4ca10f8d123eee87b7451aba xsa378/xsa378-4.15-6.patch fd4aa4447562230a6684d17e6e4c55f1e48df4773247f66ab9d01181003bc9aa xsa378/xsa378-4.15-7.patch 5305e3bc513bcd3e016ca3bbecc6cae38c8ed2b2eacb13e82f7b1f4401d3b67d xsa378/xsa378-4.15-8.patch 78390bf59344ea5dcbfa5831db3634b3f1b3aabf029160c72cdbeeec2b46b2a9 xsa378/xsa378-4.patch 76fb4a1f2604b98d3a803744ad212b3984117ec8c8011ad6db3759f9337a9b5a xsa378/xsa378-5.patch a627f8c6b7d2ffac0b6de945189f96b718aeab8e0c8bb11476a40585d6411bd7 xsa378/xsa378-6.patch 28814b51fabd3c5cb3ca249ad291781f589cddd55fc8152fdd5668c5fcdc727c xsa378/xsa378-7.patch 30e31749ade75fd5ab4c41fa27fe2124bdcc602ccc803a85e5eeec1b9c48a9c1 xsa378/xsa378-8.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-28698 / XSA-380 version 2 long running loops in grant table handling UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= In order to properly monitor resource use, Xen maintains information on the grant mappings a domain may create to map grants offered by other domains. In the process of carrying out certain actions, Xen would iterate over all such entries, including ones which aren't in use anymore and some which may have been created but never used. If the number of entries for a given domain is large enough, this iterating of the entire table may tie up a CPU for too long, starving other domains or causing issues in the hypervisor itself. Note that a domain may map its own grants, i.e. there is no need for multiple domains to be involved here. A pair of "cooperating" guests may, however, cause the effects to be more severe. IMPACT ====== Malicious or buggy guest kernels may be able to mount a Denial of Service (DoS) attack affecting the entire system. VULNERABLE SYSTEMS ================== All Xen versions from at least 3.2 onwards are vulnerable in principle. Systems running with default settings are generally believed to not be vulnerable. MITIGATION ========== The problem can be avoided by reducing the number of grant mappings Xen would allow guests to establish. For example, setting "gnttab_max_maptrack_frames=256" on the Xen command line (available from Xen 4.5 onwards) or "max_maptrack_frames=256" in the xl domain configurations (available from Xen 4.10 onwards) may be low enough for all hardware Xen is able to run on. Note that except for driver domains, guests don't normally have a need to establish grant mappings, i.e. they may be okay to run with "max_maptrack_frames=0" in their xl domain configurations. - From Xen 4.14 onwards it is also possible to alter the system wide upper bound of the number of grant mappings Xen would allow guests to establish by writing to the /params/gnttab_max_maptrack_frames hypervisor file system node. Note however that changing the value this way will only affect guests yet to be created on the respective host. CREDITS ======= This issue was discovered by Andrew Cooper of Citrix. 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. xsa380/xsa380-?.patch xen-unstable - Xen 4.15.x xsa380/xsa380-4.14-?.patch Xen 4.14.x xsa380/xsa380-4.13-?.patch Xen 4.13.x xsa380/xsa380-4.12-?.patch Xen 4.12.x xsa380/xsa380-4.11-?.patch Xen 4.11.x $ sha256sum xsa380* xsa380*/* 3b1938277665c195f6822a1170c50a853efa6bc3dcd6b2b0b9bbb0849a57bbf6 xsa380.meta 65411a0fd05d534ed2238b259aa2877331ac0e79f2dda80b424f34fffcce108a xsa380/xsa380-1.patch e6cd6d345abaad38e10d6f680fe881e874e35a7295199e5430bacd209f0b7304 xsa380/xsa380-2.patch f3b486aa99a75ab54f9e26e21a721a413f993b27dbc3e6f2fda976fe20ddbae3 xsa380/xsa380-4.11-1.patch 96a09c05ca87fe3590064ca6d269ca47b97c732401cb593ff1068ac91009f51a xsa380/xsa380-4.11-2.patch 496063cd4641258e1854a77f626cdd86c866c3ed8603bdc2ff9ab709008c84a7 xsa380/xsa380-4.12-1.patch d850e1263e89c7a718f2cddcfb639fe4a5095a1852fc35499ed16a4075d225e5 xsa380/xsa380-4.12-2.patch c23d34527a2ec68015ad78cd90365e4d80bce842ce01eeaa8cd2246021a55693 xsa380/xsa380-4.13-1.patch bd40ce749d02f343c79325488ac1348e1c9e88e698bbad351bdb0a0d3995f3e0 xsa380/xsa380-4.13-2.patch 9b06085f9a4b93c465563cd76fdc682ddb9dba968c214259425b234e7053a809 xsa380/xsa380-4.14-1.patch bf6b53880abd53b56226080d1a32839c7c8c459867104697cd76eeafc2ea382a xsa380/xsa380-4.14-2.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. HOWEVER, care has to be taken to avoid restricting guests too much, as them suddenly being unable to map grants they used to be able to map may lead to re-discovery of the issue. 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-28699 / XSA-382 version 2 inadequate grant-v2 status frames array bounds check UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The v2 grant table interface separates grant attributes from grant status. That is, when operating in this mode, a guest has two tables. As a result, guests also need to be able to retrieve the addresses that the new status tracking table can be accessed through. For 32-bit guests on x86, translation of requests has to occur because the interface structure layouts commonly differ between 32- and 64-bit. The translation of the request to obtain the frame numbers of the grant status table involves translating the resulting array of frame numbers. Since the space used to carry out the translation is limited, the translation layer tells the core function the capacity of the array within translation space. Unfortunately the core function then only enforces array bounds to be below 8 times the specified value, and would write past the available space if enough frame numbers needed storing. IMPACT ====== Malicious or buggy guest kernels may be able to mount a Denial of Service (DoS) attack affecting the entire system. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS ================== All Xen versions from 4.10 onwards are affected. Xen versions 4.9 and older are not affected. Only 32-bit x86 guests permitted to use grant table version 2 interfaces can leverage this vulnerability. 64-bit x86 guests cannot leverage this vulnerability, but note that HVM and PVH guests are free to alter their bitness as they see fit. On Arm, grant table v2 use is explicitly unsupported. Only guests permitted to have 8177 or more grant table frames can leverage this vulnerability. MITIGATION ========== The problem can be avoided by not increasing too much the number of grants Xen would allow guests to establish. The limit is controlled by the "gnttab_max_frames" Xen command line option and the "max_grant_frames" xl domain configuration setting. - From Xen 4.14 onwards it is also possible to alter the system wide upper bound of the number of grants Xen would allow guests to establish by writing to the /params/gnttab_max_frames hypervisor file system node. Note however that changing the value this way will only affect guests yet to be created on the respective host. Suppressing use of grant table v2 interfaces for 32-bit x86 guests will also avoid this 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. xsa382.patch xen-unstable - Xen 4.11.x $ sha256sum xsa382* 1254d62c8ec2c6b45c117d1483af9a71f5de0e4142c9451dd5a75ee334219542 xsa382.meta 9e500ba2bfe36bebf27262afcb9be7b02f950aed4a7b6c1738606d5ed538c2b8 xsa382.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or grant-frames-limiting mitigation 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, care has to be taken to avoid restricting guests too much, as them suddenly being unable to establish grants they used to be able to establish may lead to re-discovery of the issue. AND: Deployment of the grant table v2 disabling 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 is 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-28700 / XSA-383 version 2 xen/arm: No memory limit for dom0less domUs UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The dom0less feature allows an administrator to create multiple unprivileged domains directly from Xen. Unfortunately, the memory limit from them is not set. This allow a domain to allocate memory beyond what an administrator originally configured. IMPACT ====== Malicious dom0less guest could drive Xen out of memory and may result to a Denial of Service (DoS) attack affecting the entire system. VULNERABLE SYSTEMS ================== Only Arm systems are vulnerable. Only domains created using the dom0less feature are affected. Only domains created using the dom0less feature can leverage the vulnerability. All versions of Xen since 4.12 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. xsa383.patch xen-unstable - Xen 4.13.x xsa383-4.12.patch Xen 4.12.x $ sha256sum xsa383* 773fe38d5d182ce43b5552fcdf6ed08c33126ed728e40d94c5050f89bfb3bd4d xsa383.meta cfd0632d250cc36d88269ae08e19e742c6bd07ba130c2604d51a10ba64d4e413 xsa383.patch d18f72fa595f330fa8ed13c9412a36fba58a8baf9ad30b9fc2fd4e4533c0ee1a xsa383-4.12.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 + =========================================================