===================================================================== CERT-Renater Note d'Information No. 2024/VULN067 _____________________________________________________________________ DATE : 30/01/2024 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-449.html https://xenbits.xen.org/xsa/advisory-450.html _____________________________________________________________________ Xen Security Advisory CVE-2023-46839 / XSA-449 version 2 pci: phantom functions assigned to incorrect contexts UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= PCI devices can make use of a functionality called phantom functions, that when enabled allows the device to generate requests using the IDs of functions that are otherwise unpopulated. This allows a device to extend the number of outstanding requests. Such phantom functions need an IOMMU context setup, but failure to setup the context is not fatal when the device is assigned. Not failing device assignment when such failure happens can lead to the primary device being assigned to a guest, while some of the phantom functions are assigned to a different domain. IMPACT ====== Under certain circumstances a malicious guest assigned a PCI device with phantom functions may be able to access memory from a previous owner of the device. VULNERABLE SYSTEMS ================== Systems running all version of Xen are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only systems using PCI passthrough of devices with phantom functions are affected. MITIGATION ========== There is no mitigation (other than not passing through PCI devices with phantom functions to guests). CREDITS ======= This issue was discovered by Roger Pau Monné of XenServer. 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. xsa449.patch xen-unstable - Xen 4.17.x xsa449-4.16.patch Xen 4.16.x - Xen 4.15.x $ sha256sum xsa449* f77914aae8f917952f66d863d26314875ff96a0d8178f64c94b95825eabbc8a8 xsa449.patch 8f0302c24535ad4c7379469f33afcfdce08ba6db970e0ca1a1bfdd788af6fc6c xsa449-4.16.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches 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 mitigation 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 removing/replacing of pass-through devices or their replacement by emulated devices is a guest visible configuration change, which may lead to re-discovery of the issue. Deployment of this mitigation is permitted only AFTER the embargo ends. 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-2023-46840 / XSA-450 version 2 VT-d: Failure to quarantine devices in !HVM builds UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= Incorrect placement of a preprocessor directive in source code results in logic that doesn't operate as intended when support for HVM guests is compiled out of Xen. IMPACT ====== When a device is removed from a domain, it is not properly quarantined and retains its access to the domain to which it was previously assigned. VULNERABLE SYSTEMS ================== Xen 4.17 and onwards are vulnerable. Xen 4.16 and older are not vulnerable. Only Xen running on x86 platforms with an Intel-compatible VT-d IOMMU is vulnerable. Platforms from other manufacturers, or platforms without a VT-d IOMMU are not vulnerable. Only systems where PCI devices are passed through to untrusted or semi-trusted guests are vulnerable. Systems which do not assign PCI devices to untrusted guests are not vulnerable. Xen is only vulnerable when CONFIG_HVM is disabled at build time. Most deployments of Xen are expected to have CONFIG_HVM enabled at build time, and would therefore not be vulnerable. MITIGATION ========== There is no mitigation. CREDITS ======= This issue was discovered by Teddy Astie of Vates 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. xsa450.patch xen-unstable - Xen 4.17.x $ sha256sum xsa450* 738c79b92ab5ea57f446df3daff6564727fea5feebf8fadeb32acd0cf06ff9fb xsa450.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 + =========================================================