=================================================================== CERT-Renater Note d'Information No. 2022/VULN231 _____________________________________________________________________ DATE : 05/07/2022 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ====================================================================https://xenbits.xen.org/xsa/advisory-406.html https://xenbits.xen.org/xsa/advisory-405.html https://xenbits.xen.org/xsa/advisory-403.html _____________________________________________________________________ Xen Security Advisory CVE-2022-33744 / XSA-406 version 3 Arm guests can cause Dom0 DoS via PV devices UPDATES IN VERSION 3 ==================Public release. ISSUE DESCRIPTION ===============When mapping pages of guests on Arm, dom0 is using an rbtree to keep track of the foreign mappings. Updating of that rbtree is not always done completely with the related lock held, resulting in a small race window, which can be used by unprivileged guests via PV devices to cause inconsistencies of the rbtree. These inconsistencies can lead to Denial of Service (DoS) of dom0, e.g. by causing crashes or the inability to perform further mappings of other guests' memory pages. IMPACT ====A guest performing multiple I/Os of PV devices in parallel can cause DoS of dom0 and thus of the complete host. VULNERABLE SYSTEMS ================Only Arm systems (32-bit and 64-bit) are vulnerable. Dom0 Linux versions 3.13 - 5.18 are vulnerable. X86 systems are not vulnerable. MITIGATION ========There is no mitigation available. CREDITS =====This issue was discovered by Oleksandr Tyshchenko of EPAM. 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. xsa406-linux.patch Linux 3.13 - 5.19-rc $ sha256sum xsa406* 7a789f564b3365cade6e95d549dbbd5a8b7b5e53d09bc5a463c77dfefd5a4182 xsa406-linux.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-2022-33743 / XSA-405 version 3 network backend may cause Linux netfront to use freed SKBs UPDATES IN VERSION 3 ==================Public release. ISSUE DESCRIPTION ===============While adding logic to support XDP (eXpress Data Path), a code label was moved in a way allowing for SKBs having references (pointers) retained for further processing to nevertheless be freed. IMPACT ====A misbehaving or malicious backend may cause a Denial of Service (DoS) in the guest. Information leaks or privilege escalation cannot be ruled out. VULNERABLE SYSTEMS ================Linux versions 5.9 - 5.18 are vulnerable. Linux versions 5.8 and earlier are not vulnerable. This vulnerability only increases the capability of an attacker in systems with less than fully privileged network backends (e.g. network driver domains). For systems where netback runs in dom0 (the default configuration), this vulnerability does not increase the capabilities of an attacker. MITIGATION ========There is no mitigation available other than not using PV devices in case a backend is suspected to be potentially malicious. 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. xsa405-linux.patch Linux 5.9 - 5.19-rc $ sha256sum xsa405* 69716b78fbd996bce0414079bbb5f002029c5a82924aaae0db78a13c4b385f0a xsa405-linux.patch $ DEPLOYMENT DURING EMBARGO =======================Deployment of patches or mitigations 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 the patches need to be applied in the affected guests. Switching from PV to non-PV devices is observable by the guests and has usually a bad performance impact. Deployment is permitted only AFTER the embargo ends. (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-2022-26365,CVE-2022-33740,CVE-2022-33741,CVE-2022-33742 / XSA-403 version 3 Linux disk/nic frontends data leaks UPDATES IN VERSION 3 ==================Public release. ISSUE DESCRIPTION ===============Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742). IMPACT ====An untrusted backend can access data not intended to be shared. If such mappings are made with write permissions the backend could also cause malfunctions and/or crashes to consumers of contiguous data in the shared pages. VULNERABLE SYSTEMS ================All Linux guests using PV devices are vulnerable in case potentially malicious PV device backends are being used. MITIGATION ========There is no mitigation available other than not using PV devices in case a backend is suspected to be potentially malicious. CREDITS =====The issue related to not zeroing memory areas used for shared communications was discovered by Roger Pau Monné of Citrix. The issue related to leaking contiguous data in granted pages was disclosed publicly. RESOLUTION ========Applying the attached patches to Linux makes the disk and network frontends capable of protecting themselves against potentially malicious backends. The signaling of whether a frontend should consider a backend as potentially malicious can be done from either the Linux kernel command line or the toolstack. Two different patches are provided for each Xen branch, but only the first patch will be applied to the official Xen repository for each branch. For the xen-unstable branch patch 1 introduces a new field to the disk and nic configurations that allow signaling on a per-device basis whether the backend should be trusted. This is an ABI incompatible change, and cannot be applied to stable branches. Patch 2 introduces support to libxl for libxl_{disk,nic}_backend_untrusted environment variable to be used in order to set whether disk and network frontends should be trusted in the absence of a per-device setting. Patch 2 is provided as a courtesy for users of stable branches that might come to rely on this behavior. For the stable branches (Xen 4.16.x - Xen 4.13.x) patch 1 introduces support to libxl for libxl_{disk,nic}_backend_untrusted environment variable to be used in order to set whether disk and network backends should be trusted. Patch 2 reverts patch 1 and instead provides the more fine grained per-device options that break the libxl ABI. Note that applying patch 2 to any of the stable releases will require a rebuild of any consumers of the libxl library, as it introduces an ABI breakage and hence won't be applied to the official repository stable branches. Users of stable releases wanting to use the functionality provided by patch 2 will need to apply it manually. Regardless of the combinations of patches applied, in the absence of any environment variable mentioned above backends will be trusted by default. 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. xsa403/xsa403-?.patch xen-unstable xsa403/xsa403-4.16-?.patch Xen 4.16.x - Xen 4.15.x xsa403/xsa403-4.14-?.patch Xen 4.14.x - Xen 4.13.x xsa403/xsa403-linux-*.patch Linux 5.18 $ sha256sum xsa403*/* f28624407a3f040456ef2c52a18d8dcf486274ea082335ea38c9791646f4989c xsa403/xsa403-1.patch e06451655775009ceaf460bbba65374c05203eed295ff43fc5fa32a8d390a94a xsa403/xsa403-2.patch 5efb8af5ed5614f5e2e8d606a9debb3503cd9e114551525826fc5a7f9de91c02 xsa403/xsa403-4.14-1.patch 9ead8c6e4d694f3042c8d2fab4ea81619c4a9fc2aa7a0f485e9c873d927d283c xsa403/xsa403-4.14-2.patch ae778d5731ae663cca32d59ed9b1be51200b85c441771a9c6657c112e9550a15 xsa403/xsa403-4.16-1.patch 8ef7bd06f646fa72f22892d2b72ae44ff4e6c00d9817d52a71262be174862ee3 xsa403/xsa403-4.16-2.patch 8192d0c313448d7aa12c13d1632db3bd68835c19f60c237b87548d5c528852b0 xsa403/xsa403-linux-1.patch 4b288d3266f9396bedc7de823909aed4d1a89fe86b2edd1d625b0e32741688cf xsa403/xsa403-linux-2.patch dddf68625be516f0524fe7bb439272769cf7d612e15e00ac936bc047fd182f8a xsa403/xsa403-linux-3.patch 4e38a50a0e5ec6e90d2fffef003f8eb93a68518f4636c15cd59568ddf1861988 xsa403/xsa403-linux-4.patch $ DEPLOYMENT DURING EMBARGO =======================Deployment of patches or mitigations 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 the patches need to be applied in the affected guests. Switching from PV to non-PV devices is observable by the guests and has usually a bad performance impact. Deployment is permitted only AFTER the embargo ends. (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 + =======================================================