Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN078 _____________________________________________________________________ DATE : 27/01/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-477.html https://xenbits.xen.org/xsa/advisory-478.html https://xenbits.xen.org/xsa/advisory-479.html _____________________________________________________________________ Xen Security Advisory CVE-2025-58150 / XSA-477 version 2 x86: buffer overrun with shadow paging + tracing UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= Shadow mode tracing code uses a set of per-CPU variables to avoid cumbersome parameter passing. Some of these variables are written to with guest controlled data, of guest controllable size. That size can be larger than the variable, and bounding of the writes was missing. IMPACT ====== The exact effects depend on what's adjacent to the variables in question. The most likely effects are bogus trace data, but none of privilege escalation, information leaks, or Denial of Service (DoS) can be excluded without detailed analysis of the particular build of Xen. VULNERABLE SYSTEMS ================== Only x86 systems are vulnerable. Arm systems are not vulnerable. Only HVM guests running in shadow paging mode and with tracing enabled can leverage the vulnerability. MITIGATION ========== Running HVM guests in HAP mode only will avoid the vulnerability. Not enabling tracing will also avoid the vulnerability. Tracing is enabled by the "tbuf_size=" command line option, or by running tools like xentrace or xenbaked in Dom0. Note that on a running system stopping xentrace / xenbaked would disable tracing. For xentrace, however, this additionally requires that it wasn't started with the -x option. Stopping previously enabled tracing can of course only prevent future damage; prior damage may have occurred and may manifest only later. CREDITS ======= This issue was discovered by Jan Beulich of SUSE. 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. xsa477.patch xen-unstable - Xen 4.19.x xsa477-4.18.patch Xen 4.18.x $ sha256sum xsa477* 025783441d7db846e717a1e48547b0db7a36fcc6af652b688524c684f0c3d2a7 xsa477.patch 194da830e15195873456b145a8df83af43aaae7a82fa6cb6852928d75c68909c xsa477-4.18.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-58151 / XSA-478 version 2 varstored: TOCTOU issues with mapped guest memory UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= varstored is a component of the Xapi toolstack handling UEFI Variables for a VM. It has a communication path with OVMF inside the VM involving mapping a buffer prepared by OVMF. Within varstored, there were insufficient compiler barriers, creating TOCTOU issues with data in the shared buffer. The exact vulnerable behaviour depends on the code generated by the compiler. In a build of varstored using default settings, the attacker can control an index used in a jump table. IMPACT ====== An attacker with kernel level access in a VM can escalate privilege via gaining code execution within varstored. VULNERABLE SYSTEMS ================== Only systems using the Xapi toolstack are potentially affected. Systems running all versions of varstored are potentially affected. x86 HVM guests which have been configured as UEFI VMs can leverage the vulnerability. x86 PV guests cannot leverage the vulnerability. A Xapi VM is configured for UEFI if the `HVM-boot-params` map contains `firmware=uefi`. e.g.: xe vm-param-list uuid=$UUID ... HVM-boot-params (MRW): firmware: uefi ... If `firmware` is set to `bios`, or is absent entirely (PV guests), then the guest cannot leverage the vulnerability. MITIGATION ========== There are no mitigations. CREDITS ======= This issue was discovered by Teddy Astie of Vates. RESOLUTION ========== Applying the attached patch resolves this issue. xsa478.patch varstored master $ sha256sum xsa478* 401679429e22e202fecf418c5100144ea0ee1cca3643f09960107cf3d88821db xsa478.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-23553 / XSA-479 version 2 x86: incomplete IBPB for vCPU isolation UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= In the context switch logic Xen attempts to skip an IBPB in the case of a vCPU returning to a CPU on which it was the previous vCPU to run. While safe for Xen's isolation between vCPUs, this prevents the guest kernel correctly isolating between tasks. Consider: 1) vCPU runs on CPU A, running task 1. 2) vCPU moves to CPU B, idle gets scheduled on A. Xen skips IBPB. 3) On CPU B, guest kernel switches from task 1 to 2, issuing IBPB. 4) vCPU moves back to CPU A. Xen skips IBPB again. Now, task 2 is running on CPU A with task 1's training still in the BTB. IMPACT ====== Guest processes may leverage information leaks to obtain information intended to be private to other entities in a guest. VULNERABLE SYSTEMS ================== Xen versions which had the XSA-254 fixes backported are vulnerable. Upstream, that is 4.6 and newer. Only x86 systems are vulnerable. Arm systems are not vulerable. Systems vulnerable to SRSO (see XSA-434) with default settings use IBPB-on-entry to protect against SRSO. This is a rather more aggressive form of flushing than only on context switch, and is believed to be sufficient to avoid the vulnerability. MITIGATION ========== Using "spec-ctrl=ibpb-entry=hvm,ibpb-entry=pv" on the Xen command line will activate the SRSO mitigation on non-SRSO-vulnerable hardware, but it is a large overhead. CREDITS ======= This issue was discovered by David Kaplan of AMD. 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. xsa479.patch xen-unstable - Xen 4.18.x $ sha256sum xsa479* 82369898d0287e69272d0d65fb0e6be5fd0106bda19cedb3c9f6e75688f6fb4b xsa479.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 + =========================================================