-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmEmMPYMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZwnkIALnDReUPP6qoQzBWHf9s93UPwM6YVdHl/ao1Nh9l IyMGtTKjJjtYR9at0tIJDmVecFZzsBtLhQlKWe5DvNP84ZQ99EGDjzsqYKGdJMZK QIfyUz74UKN5PwEzxeT2C3Q9tOIq2NA41Vax19MjAXSbvAi3jp/0CSj7i6h+bK5f WoBX9Av8Ie2ykF3Fe5i7yNl9gMpCyqEl3dijWwjezLIxlxzdBrjbKni+yBvmLBS9 XdS++bu9LwAbQXeDc5oB0b6mvy+7oHzEJfvCH+tA6o6V6bls94sF8owi5H52rn1n 23HzFQwbwqX9wmW5OKSS/NBzI9vJwzRCyOEVQw+eaZQGiHw= =kWGv -----END PGP SIGNATURE-----
xsa382.meta
Description: Binary data
xsa382.patch
Description: Binary data