-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2024-31145 / XSA-460 version 2 error handling in x86 IOMMU identity mapping UPDATES IN VERSION 2 ==================== Wording updated. Public release. ISSUE DESCRIPTION ================= Certain PCI devices in a system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, "RMRR") for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with such a region is active, the mappings of these regions need to remain continuouly accessible by the device. In the logic establishing these mappings, error handling was flawed, resulting in such mappings to potentially remain in place when they should have been removed again. Respective guests would then gain access to memory regions which they aren't supposed to have access to. IMPACT ====== The precise impact is system specific. Denial of Service (DoS) affecting the entire host or individual guests, privilege escalation, and information leaks cannot be ruled out. VULNERABLE SYSTEMS ================== Only x86 systems passing PCI devices with RMRR/Unity regions through to guests are potentially affected. PCI devices listed in a vm.cfg file have error handling which causes `xl create` to abort and tear down the domain, and is thus believed to be safe. PCI devices attached using `xl pci-attach` will result in the command returning nonzero, but will not tear down the domain. VMs which continue to run after `xl pci-attach` has failed expose the vulnerability. For x86 Intel hardware, Xen versions 4.0 and later are affected. For all x86 hardware, Xen versions having the XSA-378 fixes applied / backported are affected. MITIGATION ========== Assigning devices using the vm.cfg file for attachment at boot avoids the vulnerability. CREDITS ======= This issue was discovered by Teddy Astie of Vates and diagnosed as a security issue 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 respective stable branch before applying these patches. xsa460.patch xen-unstable - Xen 4.16.x $ sha256sum xsa460* f4ca598f71e9ef6b9bc50803df2996b92d2e69afd8e36d9544823d7e56ec1819 xsa460.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 -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAma8sCIMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZiSUIAMFWxhjNzhsuUGbrUVsO6oDIs7gOcVEsC3BlcsIp LqetutOWHwR8B9jHeOjewZjgL/q1031qX+nCCcU/ilZtA7cAiVhPNrh4PSD/D9S5 RqUG3oSsFjSTtGwVl2JlqlHoE90tXOqLBhZFCJixQzaW3kbCfhDZdmufj8TQYBCQ N3ioNAGwvmSeV8QPh8l3P7TRRsMwr0OTWQYtj7r4QuW+dDPJaKzbCpmWVaCPVeI2 uKUxwwIxSE9J9L1mUR34HIJR/clCFNqlcpc/MmQVz0qprBOh4jNDunN+JNDY1VXR 3P+N50ZnHCK5w1z+vjeVvZRyp9JDt2LDUj6XJ6G9IdvN1xA= =vNzh -----END PGP SIGNATURE-----