Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN305 _____________________________________________________________________ DATE : 17/03/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-480.html https://xenbits.xen.org/xsa/advisory-481.html _____________________________________________________________________ Xen Security Advisory CVE-2026-23554 / XSA-480 version 3 Use after free of paging structures in EPT UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= The Intel EPT paging code uses an optimization to defer flushing of any cached EPT state until the p2m lock is dropped, so that multiple modifications done under the same locked region only issue a single flush. Freeing of paging structures however is not deferred until the flushing is done, and can result in freed pages transiently being present in cached state. Such stale entries can point to memory ranges not owned by the guest, thus allowing access to unintended memory regions. IMPACT ====== Privilege escalation, Denial of Service (DoS) affecting the entire host, and information leaks. VULNERABLE SYSTEMS ================== Xen 4.17 and onwards are vulnerable. Xen 4.16 and older are not vulnerable. Only x86 Intel systems with EPT support are vulnerable. Only x86 HVM/PVH guests using HAP can leverage the vulnerability on affected systems. MITIGATION ========== There are no mitigations. CREDITS ======= This issue was discovered by Roger Pau Monné of XenServer. 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. xsa480.patch xen-unstable - Xen 4.17.x $ sha256sum xsa480* 578f8fec3f34656e085419f6376d43987ffd6ed32e067b4024d3c83ce03a5901 xsa480.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-2026-23555 / XSA-481 version 2 Xenstored DoS by unprivileged domain UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= Any guest issuing a Xenstore command accessing a node using the (illegal) node path "/local/domain/", will crash xenstored due to a clobbered error indicator in xenstored when verifying the node path. Note that the crash is forced via a failing assert() statement in xenstored. In case xenstored is being built with NDEBUG #defined, an unprivileged guest trying to access the node path "/local/domain/" will result in it no longer being serviced by xenstored, other guests (including dom0) will still be serviced, but xenstored will use up all cpu time it can get. IMPACT ====== Any unprivileged domain can cause xenstored to crash, causing a DoS (denial of service) for any Xenstore action. This will result in an inability to perform further domain administration on the host. In case xenstored has been built with NDEBUG defined, an unprivileged domain can force xenstored to be 100% busy, but without harming xenstored functionality for other guests otherwise. VULNERABLE SYSTEMS ================== All Xen systems from Xen 4.18 onwards are vulnerable. Systems up to Xen 4.17 are not vulnerable. Systems using the C variant of xenstored are vulnerable. Systems using xenstore-stubdom or the OCaml variant of Xenstore (oxenstored) are not vulnerable. MITIGATION ========== There is no known mitigation available. CREDITS ======= This issue was discovered by Marek Marczykowski-Góreckiof Invisible Things Lab. 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. xsa481.patch xen-unstable - Xen 4.18.x $ sha256sum xsa481* 148147e4545a4670578c0f24aa136f67bc203c7b18ec980b8cc80cfbb04ace68 xsa481.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patch 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. Switching xenstored with oxenstored or xenstore-stubdom is not permitted as a mitigation, as this is a guest visible change of the configuration. (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 + =========================================================