Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2025/VULN592 _____________________________________________________________________ DATE : 09/09/2025 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-472.html https://xenbits.xen.org/xsa/advisory-473.html https://xenbits.xen.org/xsa/advisory-474.html _____________________________________________________________________ Xen Security Advisory CVE-2025-27466,CVE-2025-58142,CVE-2025-58143 / XSA-472 version 2 Mutiple vulnerabilities in the Viridian interface UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= There are multiple issues related to the handling and accessing of guest memory pages in the viridian code: 1. A NULL pointer dereference in the updating of the reference TSC area. This is CVE-2025-27466. 2. A NULL pointer dereference by assuming the SIM page is mapped when a synthetic timer message has to be delivered. This is CVE-2025-58142. 3. A race in the mapping of the reference TSC page, where a guest can get Xen to free a page while still present in the guest physical to machine (p2m) page tables. This is CVE-2025-58143. IMPACT ====== Denial of Service (DoS) affecting the entire host, information leaks, or elevation of privilege. VULNERABLE SYSTEMS ================== Xen versions 4.13 and newer are vulnerable. Xen versions 4.12 and older are not vulnerable. Only x86 HVM guests which have the reference_tsc or stimer viridian extensions enabled are vulnerable. MITIGATION ========== Not enabling the reference_tsc and stimer viridian extensions will avoid the issues. CREDITS ======= This issue was discovered by Roger Pau Monné of XenServer. RESOLUTION ========== Applying the appropriate set of attached patches 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. xsa472-?.patch xen-unstable - Xen 4.17.x $ sha256sum xsa472* 16e14b3cc87800c08d96adc18e66aa4a20a77834af12b9cdd01d739882f07b7d xsa472-1.patch 4be6a1066fbec367e8c9883240cec2a78671d484928d51ac5fb82e2c539e38ca xsa472-2.patch 9e1972a2b5a7a817b25cad0fa80c983198bb73a2788a4d0b5cdcaca4518a57cf xsa472-3.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches (but not 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. This is because the mitigations are guest visible changes, and hence could give hints to users about the upcoming vulnerabilities. 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-2025-58144,CVE-2025-58145 / XSA-473 version 2 Arm issues with page refcounting UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= There are two issues related to the mapping of pages belonging to other domains: For one, an assertion is wrong there, where the case actually needs handling. A NULL pointer de-reference could result on a release build. This is CVE-2025-58144. And then the P2M lock isn't held until a page reference was actually obtained (or the attempt to do so has failed). Otherwise the page can not only change type, but even ownership in between, thus allowing domain boundaries to be violated. This is CVE-2025-58145. IMPACT ====== An unprivileged guest can cause a hypervisor crash, causing a Denial of Service (DoS) of the entire host. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS ================== Xen versions 4.12 and onwards are vulnerable. Xen versions 4.11 and earlier are not vulnerable. Only Arm systems are affected. x86 systems are not affected. MITIGATION ========== There is no known mitigation. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. RESOLUTION ========== Applying the appropriate set of attached patches 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. xsa473-?.patch xen-unstable - Xen 4.19.x xsa473-4.18-?.patch Xen 4.18.x - Xen 4.17.x $ sha256sum xsa473* e70f71258f1998eddafcdb5f4cb46d98e9dedc529f102b85dfb4e5310faf48eb xsa473-1.patch a501bde6ffb7391387cffe74e3eb9bd5c06d70bd7695aa811d42c75d3903fa59 xsa473-2.patch e8a27f02e57d1a8d956cca9c9ed2db90c328911ff3a9434883baf633a0f3be5c xsa473-4.18-1.patch b2f6f4560d6082e0fb040f7352dda8963ab2dce207efce289131c10b69ebf656 xsa473-4.18-2.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-2025-58146 / XSA-474 version 2 XAPI UTF-8 string handling UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= There are multiple issues. 1. Updates to the XAPI database sanitise input strings, but try generating the notification using the unsanitised input. This causes the database's event thread to terminate and cease further processing. 2. XAPI's UTF-8 encoder implements v3.0 of the Unicode spec, but XAPI uses libraries which conform to the stricter v3.1 of the Unicode spec. This causes some strings to be accepted as valid UTF-8 by XAPI, but rejected by other libraries in use. Notably, such strings can be entered into the database, after which the database can no longer be loaded. 3. There is no input sanitisation for Map/Set updates on objects in the XAPI database. IMPACT ====== Buggy or malicious inputs to XAPI can cause a Denial of Service. VULNERABLE SYSTEMS ================== All versions of XAPI are believed to be vulnerable. Issues 1 and 2 can be leveraged by guest administrator. Issue 3 can only be leveraged by an authenticated API user. MITIGATION ========== There are no mitigations. CREDITS ======= This issue was discovered by Edwin Török from XenServer. RESOLUTION ========== An updated XAPI, built with the attached patch, needs to be deployed to resolve the issue. If XAPI restarts correctly, no further action is necessary. If bad strings have been entered into the database, XAPI will get into a restart loop, citing: [error||0 ||backtrace] Xapi.watchdog failed with exception Xmlm.Error(999:42777, "malformed character stream") in /var/log/xensource.log roughly every 4 seconds. To resolve this, the bad characters need stripping manually from the database. In dom0, something along the lines of: cd /var/xapi service xapi stop cp state.db state.bak iconv -f UTF-8 -t UTF-8//IGNORE < state.db > state.$$ mv state.$$ state.db service xapi start xsa474.patch XAPI master $ sha256sum xsa474* e3c7ce7522252b25710062f1c761b5f1e319dab2129fc7c1d9fd6440f9331a9f xsa474.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 + =========================================================