-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2021-28698 / XSA-380 version 3 long running loops in grant table handling UPDATES IN VERSION 3 ==================== New bugfix patch on top of the prior set. 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. To address an issue observed with some compiler versions, another patch needs to be applied on top. This has been committed to the unstable tree (commit hash b6da9d0414d69c2682214ee3ecf9816fcac500d0) only so far. This patch is listed last below. xsa380/xsa380-[12].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 xsa380/xsa380-3.patch Xen 4.15.x - Xen 4.11.x $ sha256sum xsa380* xsa380*/* 3b1938277665c195f6822a1170c50a853efa6bc3dcd6b2b0b9bbb0849a57bbf6 xsa380.meta 65411a0fd05d534ed2238b259aa2877331ac0e79f2dda80b424f34fffcce108a xsa380/xsa380-1.patch e6cd6d345abaad38e10d6f680fe881e874e35a7295199e5430bacd209f0b7304 xsa380/xsa380-2.patch 1ead53a28dedb0a502a700d9ea933e89e385c1582f4790f558a11d0d39e9d374 xsa380/xsa380-3.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 -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmEvSDUMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZfboH/jtTLKbkb/K4SPliIDSRym1+wx17Ho30F9IRfd7E ZdUBHfFLTEbZ/GvU+UkU914XeK49fCHZGylu2dcIRWgPmXFlqOtydFJny9a8sCjx 7/dLR1WXvhJ4eG8Hsma13uRzZuaF4JdXDp1M/QOr6aBHNTLBgMefbQNTAbFO0kzP 2xK3arGefi/eNa3GOEghrMlt2U/5r1h7PfLXBl69BETomOCOo5gyn6aQwqH/xKSY W2cmqN0hYLyQSA+jx6QuTknsvSLS6NWWPEk/xfs31Op0E/P3tga0u6hCbRvWzOmE AdISyyP8ogIBU4ekMn0H4yQoWKVgYctk3XAawBmogv+VJXI= =7wyB -----END PGP SIGNATURE-----