-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2022-23035 / XSA-395 version 2 Insufficient cleanup of passed-through device IRQs UPDATES IN VERSION 2 ==================== Adjust patch subject. Public release. ISSUE DESCRIPTION ================= The management of IRQs associated with physical devices exposed to x86 HVM guests involves an iterative operation in particular when cleaning up after the guest's use of the device. In the case where an interrupt is not quiescent yet at the time this cleanup gets invoked, the cleanup attempt may be scheduled to be retried. When multiple interrupts are involved, this scheduling of a retry may get erroneously skipped. At the same time pointers may get cleared (resulting in a de-reference of NULL) and freed (resulting in a use-after-free), while other code would continue to assume them to be valid. IMPACT ====== The precise impact is system specific, but would typically be a Denial of Service (DoS) affecting the entire host. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS ================== Xen versions 4.6 and later are vulnerable. Xen versions 4.5 and earlier are not vulnerable. Only x86 HVM guests with one or more passed-through physical devices using (together) multiple physical interupts can leverage the vulnerability. x86 PV guests cannot leverage the vulnerability. x86 HVM guests without passed-through devices or with a passed-through device using just a single physical interrupt also cannot leverage the vulnerability. Device pass-through is unsupported for x86 PVH guests and all Arm guests. MITIGATION ========== There is no mitigation (other than not passing through to x86 HVM guests PCI devices with, overall, more than a single physical interrupt). CREDITS ======= This issue was discovered by Julien Grall of Amazon. 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. xsa395.patch xen-unstable - Xen 4.15.x xsa395-4.14.patch Xen 4.14.x - Xen 4.12.x $ sha256sum xsa395* f460be598b936bb5cfb9276787f2f21d90b029d1fe10dabd572ae50f84a1124d xsa395.meta 295b876c52cf5efe19150757275da3d154beb72ac2d7be267e16c9262e410de3 xsa395.patch 5697f3137e0a202744f31b1c6cbcfa459d8fa9b4b68be59561b78c40fe1233c5 xsa395-4.14.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/4UyVfoK9kFAmHv39QMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZhowIAIZYZq4efyEAP5rB3zX4yRel2GNz+2Dpjok4PExB uSOrPaH5dDILhNdVJNG48MckDe0dMDsn3OGr1I6lbxcV1TWR1JFrBQoxeUnwdiEf GjeTni0hhefan3IEEd5HUDInQgf9oI7fUcgEdVAoIV87BQdlK0ofjJ3TggSrr8jl pL5dmIh4OICD6YttR11Of1vhPY2WhZQb2xgSxzEQbDeY8k3JaRWy8mYwwxPD0HXn +hmLK59ZhkJd5Sk8AxttRUTEsl6nKESrUz3vv/vFInV5Go+35AElL//gQNgOOTAS nljLLtJdfHSuRy459Sw/lm4mwQ9zkfOFH6B+M6efSkHMyoE= =Iv+w -----END PGP SIGNATURE-----