Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN798 _____________________________________________________________________ DATE : 29/07/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Xen. ===================================================================== https://xenbits.xen.org/xsa/advisory-495.html https://xenbits.xen.org/xsa/advisory-496.html https://xenbits.xen.org/xsa/advisory-497.html https://xenbits.xen.org/xsa/advisory-498.html https://xenbits.xen.org/xsa/advisory-499.html https://xenbits.xen.org/xsa/advisory-500.html https://xenbits.xen.org/xsa/advisory-501.html https://xenbits.xen.org/xsa/advisory-502.html https://xenbits.xen.org/xsa/advisory-503.html https://xenbits.xen.org/xsa/advisory-504.html https://xenbits.xen.org/xsa/advisory-505.html https://xenbits.xen.org/xsa/advisory-506.html https://xenbits.xen.org/xsa/advisory-507.html https://xenbits.xen.org/xsa/advisory-508.html _____________________________________________________________________ Xen Security Advisory CVE-2026-42493 / XSA-495 version 2 x86 shadow paging is deprecated UPDATES IN VERSION 2 ==================== Updated the patch for staging with further CI adjustements. Public release. ISSUE DESCRIPTION ================= Addressing certain issues, in particular related to operations which may take excessively long and therefore would need preemption, has turned out overly costly. Since alternatives (HVM/PVH: HAP, PV: shim) are commonly available, the decision was to deprecate the functionality, while still retaining it for people to use at their own (security) risk. Memory-wise small enough guests may still be okay to run. IMPACT ====== An unprivileged guest may be able to cause Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS ================== All x86 systems with builds of Xen having SHADOW_PAGING=y are affected. Note that prior to Xen 4.7 this control didn't exist, and all builds of Xen would be affected. (Strictly speaking Xen 4.6 had a different, harder to use mechanism to disable shadow paging support: One could pass "shadow-paging=n" on the make command line.) MITIGATION ========== Running HVM and PVH in Hardware Assisted Paging (HAP) mode will avoid this vulnerability. There's no mitigation available for PV guests. This is because shadow mode, if support is enabled in the hypervisor, could be engaged at any time. Note that without shadow mode built into Xen, guests not properly dealing with L1TF will simply be crashed instead. RESOLUTION ========== Applying the appropriate attached patch documents 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. xsa495.patch xen-unstable - Xen 4.22.0 xsa495-4.21.patch Xen 4.21.x xsa495-4.20.patch Xen 4.20.x - Xen 4.19.x xsa495-4.18.patch Xen 4.18.x xsa495-4.17.patch Xen 4.17.x $ sha256sum xsa495* 949624ce241ddc455c43cdde0ff045cc5fdf29b69f06f7079fa8f1d2400e1d9d xsa495.patch bb1fea4b49840b81a1a7ca86124e308f23edd6eb078857d44d9ebaf1b352b374 xsa495-4.17.patch 06f2c862df85a17b9dc1d4a0df42cadb97e24b7033c070c9ad74ad72d278af0e xsa495-4.18.patch bffa5816be9ddf0fabec0509f2b74e30a5dd0e5429a3b7919e304150cb5091f2 xsa495-4.20.patch 7092cf37dbcfecc9aa6bf9a2836ed70f48f52bccb9630e94c89d2afe120b47f5 xsa495-4.21.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of patches or mitigations is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because switching HVM or PVH guests from shadow to HAP mode is a guest noticeable change, while for PV guests the lack of shadow mode is noticeable because they then cannot be migrated anymore, and guests not properly fixed for L1TF would be forcibly crashed. Deployment is permitted only AFTER the embargo ends. (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-42494,CVE-2026-42495,CVE-2026-62423,CVE-2026-62424,CVE-2026-62425 / XSA-497 version 2 buffer overruns in libfsimage iso9660 handling UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver derives several lengths directly from attacker-controlled on-disk fields without validating them: * The directory loop itself assumes a good record length. This is CVE-2026-42494. * The calculation of the System Use area may underflow. This is CVE-2026-42495. * The Rock Ridge extension loop assumes a good (inner) record length. This is CVE-2026-62423. * The Rock Ridge NM record processing assumes a good entry length. This is CVE-2026-62424. * The Rock Ridge CE record processing assumes a good size and offset. This is CVE-2026-62425. IMPACT ====== A guest using pygrub can escalate its privilege to that of the domain construction tools (i.e., normally, to control of the host). If the mechanism introduced by XSA-443 (see the mitigation section below) is in use, then the guest can only escalate to this limited context. VULNERABLE SYSTEMS ================== All Xen versions from at least 3.2 onwards are affected. Older versions have not been inspected. MITIGATION ========== XSA-443 added a mechanism to run pygrub de-privileged. Using this mode will mitigate the vulnerability. Ensuring that guests do not use the pygrub bootloader will avoid this vulnerability. For cases where the PV guest is known to be 64bit, and uses grub2 as a bootloader, pvgrub is a suitable alternative to pygrub. Running only HVM or PVH guests will avoid the vulnerability. CREDITS ======= This issue was discovered by Syed Abdul Khaliq of BugQore. 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. xsa497.patch xen-unstable - Xen 4.17.x $ sha256sum xsa497* 65925ac5a322b9eacc8538d6486e3e37ddcb83fe6f02f61c18216ccd2770f964 xsa497.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-42491 / XSA-498 version 2 XAPI: Missing TLS verification in some SDKs UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= XAPI provides SDKs; bindings for the API in various programming languages. These are artefacts from a build of XAPI, intended for integration into 3rd party products. In all SDKs, there is a main RPC connection to the XAPI host. TLS for this connection is verified properly, or delegated to the 3rd party logic, in all language bindings. There are also certain HTTP handlers which open a separate connection to the XAPI host. For two of the language bindings only (C# and Powershell), TLS verification is improperly implemented on these connections. IMPACT ====== A malicious actor able to perform a Man-in-the-Middle attack on the network communication between a program using one of the affected SDKs and a host running XAPI may be able to intercept the communication and: * Steal a session token, allowing for hijack of the administrative session, or * Read or tamper with exported/imported disk images, host backups, RRD (performance) data and patches/updates in transit. VULNERABLE SYSTEMS ================== This issues has been present in the XAPI C# and Powershell SDKs since TLS support was added. MITIGATION ========== There are no known mitigations. CREDITS ======= This issue was discovered by the Veeam Team. RESOLUTION ========== Applying the attached patch to XAPI master will generate fixed SDKs. 3rd party programs using vulnerable SDKs must be rebuilt against the fixed SDKs. xsa498.patch XAPI master $ sha256sum xsa498* f2db9e16561edc59b920e0ed95cce3a19147abc6eb2b8500bd73b87dc285d4ba xsa498.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-62426,CVE-2026-62427 / XSA-499 version 2 sysctl and platform-op locks open to abuse UPDATES IN VERSION 2 ==================== Add further tags to patches. Public release. ISSUE DESCRIPTION ================= To manage the system, sysctl and platform operations are used by the control domain or a possible Xenstore domain. Some of these operations may not be executed in parallel, so a system-wide lock each is used. The way those locks are acquired is, however, not providing any fairness. Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking. The sysctl issue is CVE-2026-62426. The platform-op issue is CVE-2026-62427. IMPACT ====== A less privileged entity may stall an equally or more privileged entity, potentially leading to a Denial od Service (DoS) of up to the entire host. VULNERABLE SYSTEMS ================== All Xen versions from 4.0 onwards are vulnerable. Earlier versions use a different locking operation, but may also be vulnerable. 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: The patches include an adjustment to the default Flask policy. When custom policies are in use, a respective change will need making there. 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. xsa499/xsa499-?.patch xen-unstable - Xen 4.21.x xsa499/xsa499-4.20-?.patch Xen 4.20.x - Xen 4.19.x xsa499/xsa499-4.18-?.patch Xen 4.18.x xsa499/xsa499-4.17-?.patch Xen 4.17.x $ sha256sum xsa499*/* 1b716186d37cb6be7b2917bc4801a5d431111f6a01f6e710e2899b6fbf91d747 xsa499/xsa499-1.patch 7789699993f993aa0f118437b9a18c2207cf29491fa08f21e029aa4293698d38 xsa499/xsa499-2.patch 4860a286a7161a407a7e7dc95ecb04a453847295ca73f91f3bd07c3e9e94b7fe xsa499/xsa499-3.patch fd59436b871caad09017da250996968797ada23223b1e76f9a2e80ae814d63ca xsa499/xsa499-4.17-1.patch 9f83e4866fd20a3e45ecf40a80898446d243444fdf4c17eb695ff7f3d3e9f816 xsa499/xsa499-4.17-2.patch e7e4fcb7502deb605a854ce451403237ea295394dc30f771001680cc3aaa8f9e xsa499/xsa499-4.17-3.patch 3a979d5c59d690313ec9c3d82d8859dadd6d106296cbf6fe75ef9b42f2626bb5 xsa499/xsa499-4.17-4.patch d2b3bcad9eb0d82f16befff35ef8fa0d8ed6d06b7e7e2c360003f1eee14d26b2 xsa499/xsa499-4.17-5.patch ac1f4d1935dc7546c32e5b9c42ebd08d71ca232e559a7021e3ed685c0973675e xsa499/xsa499-4.17-6.patch 143a9b46b3edf689e8b75fb87d1e15b0f0b96baf48547f6d77c00ba5e90ea5ac xsa499/xsa499-4.17-7.patch cd51ddc70ac765ef00a404d3a21c04a0e234ebca1904159820504e10f70e3812 xsa499/xsa499-4.18-1.patch 32f7827da6a6cdff848a1b620dd1a4d4861008f53d31050c6cde1d353794d22f xsa499/xsa499-4.18-2.patch 3ed288dd99051ebb014cf1cd124d5ed0837935bb0d56963f54699a9e3a966c4e xsa499/xsa499-4.18-3.patch 86fecda24801913f408f86db0b02d0017e870fa95e6edfe5d414343c89b29b37 xsa499/xsa499-4.18-4.patch 055c9114e0c1e789ee510dfb739bf8067a7acbdad6b6edaf2c0e7ed3daac2b81 xsa499/xsa499-4.18-5.patch 211b7410562f438e82266d3101beaef32d66c54b4681a370dd3e47abeec7c5c5 xsa499/xsa499-4.18-6.patch a0849d860536a199ebeabb6199012d9eae70ee2ed41573765af50aec7b7e7f85 xsa499/xsa499-4.18-7.patch 48b96df5981193f182eda567ad65f1343718656a36ea1ef2d24bdc534ea4ead1 xsa499/xsa499-4.20-1.patch 3e9a315184f64d41011721b2f09275fcc6969d46be3c6f6b788b65fe78c1a0a8 xsa499/xsa499-4.20-2.patch cf66937eecf0b8a559e60553c21de0e3767270df022c7098d7dd94a46c5ad176 xsa499/xsa499-4.20-3.patch 8932a1480b7431a0ebb048312dda49d5b7d06a5d2b57efb04df0b90bc81e95be xsa499/xsa499-4.20-4.patch 6777a824bc0248f8e12a71f87b60a3209a7a74a08fe7e072d26f80095d188a01 xsa499/xsa499-4.20-5.patch 3ab8c66b133d2b942f7caad0251d427076ad2ef38bcbf6672a937c1406f098ac xsa499/xsa499-4.20-6.patch 1254cc886eb62d65624bcc417701c119e02cc35d31f62e3dda1bda062e170446 xsa499/xsa499-4.20-7.patch 70c315beca0afa411c9e31117d8e0b22b36b5cd70e8d9d2243f5501167a2c631 xsa499/xsa499-4.patch d0ff37c4807445bd5146057ddaed31d7ce5a0fe6abf413a04f4bceca8419baeb xsa499/xsa499-5.patch 961d31a715ae2c8dd25b74243a6c759ce8c43409c4156ae6bbdcf3faac03f592 xsa499/xsa499-6.patch 60cb3b1e4beef97d633a0156feb0f4f10ac8d21c54152969f5b7a77ecc4a24d3 xsa499/xsa499-7.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-62428 / XSA-500 version 2 grant-table: type confusion in grant-copy UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= When grant-copy operations are processed, the respective grant may or may not already be in use by another operation (a mapping or another copy). For all copy operations the referenced guest frame is looked up. When another operation is already active for the grant (the grant is "pinned"), what is being supplied back to actually carry out permission checks and copy operation may not be consistent: The permission check may be carried out on a page different from the one involved in the copy. IMPACT ====== An unprivileged guest may be able to elevate its privileges to that of the host. Information leaks and Denial of Service (DoS) are possible as well. VULNERABLE SYSTEMS ================== All Xen versions from 4.2 onwards are vulnerable. Xen versions 4.1 and earlier are not vulnerable. Xen versions 4.13 and newer offer a way to build Xen without grant table support. Such hypervisors (CONFIG_GRANT_TABLE turned off) are not vulnerable. MITIGATION ========== There is no known mitigation. CREDITS ======= This issue was discovered by Roman S. 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. xsa500.patch xen-unstable - Xen 4.18.x xsa500-4.17.patch Xen 4.17.x $ sha256sum xsa500* e09e06ef5d4044b4c6104ae83d5e509d45495d7bab1da73f2beb7a916d24f462 xsa500.patch 5fabb02fd4cc62f58a07a8322883b04c638832f65fdf0216a0efde6229d1fd73 xsa500-4.17.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-62435,CVE-2026-62436 / XSA-501 version 4 grant-table: version change racing with other operations UPDATES IN VERSION 4 ==================== Properly sync backports with staging patch (there was no functional issue, just a code arrangement one). Public release. ISSUE DESCRIPTION ================= With the introduction of Grant Table v2 came the requirement to be able to switch between versions. Switching from v1 to v2 reduces the number of valid grant references, as a bigger shared entry structure is then needed while the shared table doesn't change size. Switching from v2 back to v1 the status frames, which are separate in v2, go away. Code holding, but intermediately dropping and then re-acquiring the grant table lock, sometimes wrongly assumes that said properties wouldn't change across the window in time where the lock is not being held. The v1 -> v2 issue is CVE-2026-62435. The v2 -> v1 issue is CVE-2026-62436. IMPACT ====== An unprivileged guest may be able to elevate its privileges to that of the host. Information leaks and Denial of Service (DoS) are possible as well. VULNERABLE SYSTEMS ================== All Xen versions from 4.0 onwards are vulnerable. Xen versions 3.4 and earlier are not vulnerable. Only x86 guests permitted to use grant table version 2 interfaces can leverage this vulnerability. On Arm, grant table v2 use is explicitly unsupported. Only multi-vCPU guests can leverage this vulnerability. Xen versions 4.13 and newer offer a way to build Xen without grant table support. Such hypervisors (CONFIG_GRANT_TABLE turned off) are not vulnerable. MITIGATION ========== Using the "gnttab=max-ver:1" hypervisor command line option will avoid the vulnerability. Using the "max_grant_version=1" guest configuration option for guests will also avoid the vulnerability. CREDITS ======= This issue was discovered by Mark Esler. 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. xsa501.patch xen-unstable - Xen 4.19.x xsa501-4.18.patch Xen 4.18.x xsa501-4.17.patch Xen 4.17.x $ sha256sum xsa501* e856d64f5b1a16dbb3d7ec19140f24eca508b62de0d25036fa5735cdd5b72be6 xsa501.patch e006c4fe0a35698318eca59ce828202cac19327f5139d51645116124fc3126e8 xsa501-4.17.patch 10477adfd82fa09123f08497d6a5d44ae61f48d026590ce262cac65f482b2d97 xsa501-4.18.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public- facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because restricting the available grant table version is a guest visible configuration change, which may lead to re-discovery of the issue. Deployment of this mitigation is permitted only AFTER the embargo ends. AND: 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-62429 / XSA-502 version 3 vNUMA domain cleanup may race other operations UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= Accessing the vNUMA configuration data of a guest is still possible when domain destruction has already started. The cleaning up of that configuration information is not synchronized with its retrieval by a device model controlling the guest. IMPACT ====== While Denial of Service (DoS) affecting the entire host and information leaks and are the prevailing effect, a device model stub domain or a de-privileged device model running in the control domain may also be able to elevate its privileges to that of the host. VULNERABLE SYSTEMS ================== All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier are not vulnerable. Only entities controlling guests (on x86: HVM guests) can leverage the vulnerability. These are device models running in either a stub domain or de-privileged in Dom0. Only guests which have vNUMA enabled allow their controlling entities to leverage the vulnerability. MITIGATION ========== On x86, running only PV or PVH guests will avoid the vulnerability. Not enabling vNUMA for HVM guests will also avoid the vulnerability. CREDITS ======= This issue was discovered by Teddy Astie of Vates. 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. xsa502.patch xen-unstable - Xen 4.22.0 xsa502-4.21.patch Xen 4.21.x - Xen 4.19.x xsa502-4.18.patch Xen 4.18.x - Xen 4.17.x $ sha256sum xsa502* e6150a6c468906a1bbcd4b9fca1f28cf3dc2c4617d6aab7c48507dbac003df82 xsa502.patch f780c280539aedb3eeb4f5a43f3d2f4bc5a112ca1a2d7ad6a95eb2fbdc5f5cc8 xsa502-4.18.patch a0b2b6f543a566e997a9f38bbd718cc81e8de8e7b442ff47e92260f70e66f647 xsa502-4.21.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public- facing systems with untrusted guest users and administrators. HOWEVER, deployment of the mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because no longer exposing vNUMA is a guest visible configuration change, which may lead to re-discovery of the issue. Deployment of this mitigation is permitted only AFTER the embargo ends. AND: 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-62430 / XSA-503 version 2 x86: Out-of-bounds read in vRTC emulation UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= Accesses to the CMOS memory contents are done using an indirect IO port pair. Therefore Xen needs to cache the guest chosen index, and one of the usages of the index didn't take the necessary locking to avoid concurrent changes. As a result, a guest could change the index after it being checked, causing a subsequent out-of-bound read access to the contents of an array. IMPACT ====== An attacker can read out-of-bounds, this is limited to Xen data, and not data belonging to other guests. VULNERABLE SYSTEMS ================== All Xen versions from 3.2 onwards are vulnerable. Xen versions 3.1 and earlier are not vulnerable. MITIGATION ========== Running only PV or PVH guests will avoid the vulnerability. 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. xsa503.patch xen-unstable - Xen 4.19.x xsa503-4.18.patch Xen 4.18.x - Xen 4.17.x $ sha256sum xsa503* 86ffb287767aa410e2c6b970db5167d743ca3c788b43522d46d06f41caead929 xsa503.patch 3a09ea83f092ade72c8d107c91b480f44e5c865d7f36306db8490403db9aa7ed xsa503-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-2026-62431 / XSA-504 version 2 Viridian STIMER division by zero UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The logic to handle periodic Viridian STIMERs performs a division with an unchecked user-controlled divisor value, that can be set to zero to cause a #DE fault. IMPACT ====== Enabling Viridian STIMERs to unprivileged HVM guests can result in a Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS ================== All Xen versions from 4.13 onwards are vulnerable. Xen versions 4.12 and earlier are not vulnerable. Only HVM guests with Viridian STIMERs enabled can trigger the vulnerability. MITIGATION ========== Not enabling Viridian STIMERs for HVM guests will avoid the vulnerability. Note Viridian extensions are not enabled by default. 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. xsa504.patch xen-unstable - Xen 4.17.x $ sha256sum xsa504* cc142e53866a27f3c97bd8532f42df2197f9e8e85fb3846b6fcd682d854e5689 xsa504.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches 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-62432 / XSA-505 version 2 evtchn: Race between FIFO expand and reset UPDATES IN VERSION 2 ==================== Typo correction in description. Public release. ISSUE DESCRIPTION ================= The EVTCHNOP_expand_array hypercall checks for whether FIFO event channels are enabled, but without holding the correct lock. It can race with EVTCHNOP_reset, resulting in dereferencing a NULL pointer. IMPACT ====== A malicious HVM guest (x86 HVM or PVH, and ARM) can crash Xen leading to a denial of service. A malicious x86 PV guest can most likely crash Xen leading to a denial of service, but memory corruption or privilege escalation cannot be ruled out. VULNERABLE SYSTEMS ================== All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier are not vulnerable. MITIGATION ========== There are no mitigations. 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. xsa505.patch xen-unstable - Xen 4.17 $ sha256sum xsa505* 80619fdbb547dea191439ef1c9539fa0991e8f6c449b3970a086f3287fb9ce6e xsa505.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-62433 / XSA-506 version 2 correct buffer checks for DM_OP hypercalls UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= Parts of the DM_OP handling code assumes the caller has provided the required number of buffers for the given operation without any checking being done. As a result, certain operations might access stack rubble as structures are possibly uninitialized. IMPACT ====== A device model of a HVM guest can gain insight on the contents of the Xen stack, thus possibly leaking data from other guests contexts. VULNERABLE SYSTEMS ================== All Xen versions from 4.10 onwards are vulnerable. Xen versions 4.9 and earlier are not vulnerable. Only entities controlling HVM guests can leverage the vulnerability. These are device models running in either a stub domain or de-privileged in Dom0. MITIGATION ========== Running only PV or PVH guests will avoid the vulnerability. (Switching from a device model stub domain or a de-privileged device model to a fully privileged Dom0 device model does NOT mitigate this vulnerability. Rather, it simply recategorises the vulnerability to hostile management code, regarding it "as designed"; thus it merely reclassifies these issues as "not a bug". The security of a Xen system using stub domains is still better than with a qemu-dm running as a Dom0 process. Users and vendors of stub qemu dm systems should not change their configuration to use a Dom0 QEMU process.) 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. xsa506.patch xen-unstable - Xen 4.17.x $ sha256sum xsa506* 7fa79f0421eafa420f7af791ad35a96a769c945260d81419052611771347b411 xsa506.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-62434 / XSA-507 version 2 PoD: Don't try to reclaim special pages UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= A guest started with Populated on Demand enabled (PoD) can attempt to reclaim pages which aren't regular guest RAM. This can cause corruption of memory management state in Xen. IMPACT ====== A buggy or malicious guest can cause corruption of Xen's state, leading to crashes or other malfunctions. Information leak and privilege escalation cannot be ruled out. VULNERABLE SYSTEMS ================== All Xen versions from 3.4 onwards are vulnerable. Xen versions 3.3 and earlier are not vulnerable. Only x86 systems are vulnerable. Only x86 HVM and PVH guests started in populate-on-demand mode are believed to be able to leverage the vulnerability. Populate-on-demand mode is activated when the guest's xl configuration file specifies a "maxmem" value which is larger than the "memory" value. MITIGATION ========== Running only PV guests or HVM/PVH guests without PoD will avoid the vulnerability. 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. xsa507.patch xen-unstable - Xen 4.17.x $ sha256sum xsa507* 41485ddf0912cfa53fa05e236aa27c3c6490919ac2dab5b9f57ed69f5b38f60a xsa507.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 XSA-508 version 2 pygrub is only supported in de-privileged mode UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= XSA-443 and XSA-497 addressed specific issues in specific file system drivers (libfsimage) used by pygrub. Further issues were reported, and yet more are to be expected. XSA-443 introduced a means to run pygrub de-privileged. Only this mode of operation is security supported from now on. IMPACT ====== A guest using pygrub can escalate its privilege to that of the domain construction tools (i.e., normally, to control of the host). VULNERABLE SYSTEMS ================== All Xen versions from at least 3.2 onwards are affected. Older versions have not been inspected. MITIGATION ========== XSA-443 added a mechanism to run pygrub de-privileged. Using this mode will mitigate the vulnerability. Ensuring that guests do not use the pygrub bootloader will avoid this vulnerability. For cases where the PV guest is known to be 64bit, and uses grub2 as a bootloader, pvgrub is a suitable alternative to pygrub. Running only HVM or PVH guests will avoid the vulnerability. RESOLUTION ========== Applying the attached patch documents this issue. Patches for XSA-443 added additional functionality to pygrub and libxl in order to run pygrub in a restricted environment using a specific UID. Check xl.cfg man page for information on the bootloader_restrict option. 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. xsa508.patch xen-unstable - Xen 4.17.x $ sha256sum xsa508* f1e4b6490228b7fac61fd968229f98a3dfb782d56c6729d3fe01bc34c77fbd5c xsa508.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 + =========================================================