Latest vulnerabilities for "xen project xen"

Xen Project XenArm: multiple issues with GNTTABOP_cache_flush

Risk 46

Severity

7.5

Integer Underflow

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]

1) XSA-437 (CVE-2023-34321) addressed issues with overflows in calculations involved in guests flushing caches through GNTTABOPcacheflush. Unfortunately the fix there introduced a calculation which may underflow, resulting in a loop which would - at least on 64-bit Arm - take excessively long, and which would likely eventually crash the hypervisor.

This is CVE-2026-102699.

2) GNTTABOPcacheflush may be issued on memory mapped from another domain using the grant table interface. However there was no restriction to disallow the use of invalidate-without-clean against read-only grant mappings, which may corrupt the granted memory.

This is CVE-2026-102702.

First published (updated )

CVE-2026-102699

Xen Project Xenx86: XPTI may break on huge-memory systems

Risk 76

Severity

8.8

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

XPTI (Xen Page Table Isolation) was introduced to mitigate Meltdown (CVE-2017-5754, one aspect of XSA-254). This involves copying 64-bit PV guest page table entries from guest-chosen root page tables to the Xen- chosen one which is in actual use by hardware. To read the guest root page table, the directmap is used. PV guests, however, have a directmap which may not cover all memory; in particular this is the case if any memory extends beyond the 5 TiB (CONFIGBIGMEM=y: 3.5 TiB) address boundary.

First published (updated )

CVE-2026-79609

Xen Project Xenx86/AMD: ineffectual Zenbleed workaround

Risk 90

Severity

9.8

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

The workaround for XSA-433 (Zenbleed, CVE-2023-20593) was later re-worked to better integrate with other manipulations of the same MSR. In this rework an inverted conditional was introduced, resulting in the workaround to not be applied when needed and vice versa.

For more details, see: http://xenbits.xen.org/xsa/advisory-433.html

First published (updated )

CVE-2026-79608

oss-secXen Security Advisory 520 v2 (CVE-2026-102700) - gnttab: cache-flush handling may cause page fence leak

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-102700 / XSA-520 version 2

gnttab: cache-flush handling may cause page reference leak

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

With its original introduction, GNTTABcacheflush was made available uniformly. XSA-232 (CVE-2017-14318) then covered an omitted NULL pointer check, yet the addition of that check failed to adjust the subsequent error path. That error path fails to drop a page reference in case the specified page is owned by a special system domain (DOMIO and DOMCOW are system domains which can have memory pages assigned to them.)

IMPACT ======

The most likely outcome is Denial of Service (DoS) of either Domain 0 (then likely affecting the entire host) or of another domain.

VULNERABLE SYSTEMS ==================

Xen versions 4.5 through 4.20 are affected. Xen versions 4.21 and newer as well as 4.4 and older are not affected.

Only x86 systems are vulnerable. Arm systems are not vulnerable.

MITIGATION ==========

There is no known mitigation.

CREDITS =======

This issue was discovered independently by Andrew Cooper of Citrix and Yehyeong Lee.

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.

xsa520.patch Xen 4.20.x - Xen 4.17.x

$ sha256sum xsa520 e6814fe4a77d38f83c7bf3b92e8d24a0d95508572b845c622985e7021338cca9 xsa520.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/4UyVfoK9kFAmrOItgMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZw3AIALH4pnPt5g51TX1HIUUjtyqxK9j6IyFtYgHqptRA XTaZAD+NlU9R97SKGG8/YkMwdIDOQ43HE0sjJpARScQbCXcoq781yf4U1xbuy56z prClo+bFT61BnbJnzpQuhmZ1kfPYhqqeYSEsm9TUj6g1Z3j2oq45aISrgyDJgsRJ /t8Reelp/kFhQHql7Bt7uRy0xYTHcYuN56dGDAJJ1MsExsbEdLW4hgIcTjBkD04A 29MSv3j1WlCpWSCIEs27dzJv3i5mrcp1hSXfDo84NYMzxEY9FRcSGPNaGiG0/5pG gRe67qr5htHW8rYiTjJRc2b/Sp6D1f7+QThqcq010NwdrzE= =v0su -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q4/148

oss-secXen Security Advisory 519 v2 (CVE-2026-102699,CVE-2026-102702) - Arm: multiple issues with GNTTABOP_cache_flush

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-102699,CVE-2026-102702 / XSA-519 version 2

Arm: multiple issues with GNTTABOPcacheflush

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

1) XSA-437 (CVE-2023-34321) addressed issues with overflows in calculations involved in guests flushing caches through GNTTABOPcacheflush. Unfortunately the fix there introduced a calculation which may underflow, resulting in a loop which would - at least on 64-bit Arm - take excessively long, and which would likely eventually crash the hypervisor.

This is CVE-2026-102699.

2) GNTTABOPcacheflush may be issued on memory mapped from another domain using the grant table interface. However there was no restriction to disallow the use of invalidate-without-clean against read-only grant mappings, which may corrupt the granted memory.

This is CVE-2026-102702.

IMPACT ======

A malicious unprivileged guest may crash the hypervisor, causing a Denial of Service (DoS) affecting the entire host, or corrupt memory belonging to another domain. Privilege escalation and information leaks cannot be ruled out.

VULNERABLE SYSTEMS ==================

All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier are not vulnerable.

Only Arm systems are vulnerable. x86 systems are not vulnerable.

MITIGATION ==========

There is no known mitigation.

CREDITS =======

CVE-2026-102699 was discovered by Leonid Komarianskyi of EPAM. It was later independently reported by Ayan Kumar Halder of AMD.

CVE-2026-102702 was found by the security team while looking at the surrounding code.

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.

xsa519-?.patch xen-unstable - Xen 4.21.x xsa519-4.20-?.patch Xen 4.20.x - Xen 4.17.x

$ sha256sum xsa519 3abfe7776402ba82d54b72163427694055cc3a5a729fd50a15af58699fef7903 xsa519-1.patch 6f09a24c5c793570e290ec853220099c617e372d96b93f938439ac4a18191dd2 xsa519-2.patch 1ed852f7e22fafe75e278dc913377fda5b0b73c8af51fe872684eb5b0bcb9597 xsa519-4.20-1.patch df5ba864761f3274df817fa362e234afb4b5e3f95b47daf25a307ac3d922aab6 xsa519-4.20-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 -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmrOIrAMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ9ccIALBHbUY7GDoW1oFxKSpvrFFzwdSeq+yR7Y+cnBy7 6j9ehJE2zC1qLqHy0MQjFcmdSvdm/1Qy4CZ+cZgKtOMCeOvV8OwA6QkuHV5fch0f 2wHq71u/9p7wWhsILb9EHaUHBFNXiQ+joahKPyX4FHwz2aCB+aodqCRMsvk0Kd7K PSX4FotvGHSfgxrdzP6oLPOrmvVwy91ienOabE7QMTW2anghDIFVfjycYuebfXxF S+d7ciAcHdd72fOhM/wVlXZohslxw14ESJYZMUOvha8godQjPwCtT/A/SDc/k0Et 98xImFp4NU9W4Pk42eS+JUs3KNLWFapzVePRQ0Ku80Ia6wg= =xgyt -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q4/147

oss-secXen Security Advisory 518 v2 (CVE-2026-79611) - VMX: VMentry failuwith branch tracing and blocked states

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-79611 / XSA-518 version 2

VMX: VMentry failure with branch tracing and blocked states

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

For XSA-308 logic was introduced, as VMX VMEntry checks do not like the exact combination of state which occurs when #DB in intercepted, Single Stepping is active, and blocked by STI/MovSS is active, despite this being a legitimate state to be in. The resulting VMEntry failure is fatal to the guest.

Sadly there is another special sub-case of the above, with branch tracing enabled. In that case the prior adjustment would still cause a VMentry failure, as before fatal to the guest.

IMPACT ======

HVM/PVH guest userspace code may be able to crash the guest, resulting in a guest Denial of Service.

VULNERABLE SYSTEMS ==================

All versions of Xen are affected.

Only systems supporting VMX hardware virtual extensions (Intel, VIA or Zhaoxin CPUs) are affected. Arm as well as AMD and Hygon systems are unaffected.

Only HVM/PVH guests are affected. PV guests cannot leverage the vulnerability.

MITIGATION ==========

Running only PV guests will avoid this vulnerability.

Running HVM guests on only AMD or Hygon hardware will also avoid this vulnerability.

CREDITS =======

This issue was discovered by Claude Opus and diagnosed as a security issue 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.

xsa518.patch xen-unstable - Xen 4.21.x xsa518-4.20.patch Xen 4.20.x - Xen 4.17.x

$ sha256sum xsa518 a703af59b22f1e47543af0668c8715b4e4011ba4fc05fd8b94bf05503dce88ef xsa518.patch a1a1b3548166e051f62a0759af5df8d365f524ae52f4bbbe642d45692a1f8bde xsa518-4.20.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. -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmrOIooMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZTOUIAMMapd/RMFzQxmwdwICbmj2zDnEWutkzQyV0bMMK Ui2VleXQ7pDWH5OEfDNl6644Gs6x4zB9lrTZFubAFvXjqNUk9C3QxU6LOlV0RQAq a96/glbPhXhOONdn1K5DuJq35sKjhGdsy8B+Ati+IGPstT8bGytrz+CVbdR1bnLb 3XvnRHqFSEHoQxejE/aRXpRw4k1HHD5wFQ/WfvgOEKYj+Ghjm+KE2sNhcahxxFf4 ys8v9JWBKhnLAe+mJIiMPGiKmX5uUVl6HhdX6SjTHuzzbsmITF3VOwsnHZR9vLn1 BqUwLG/uQKes4LRinfOA5RrOMt/q/ChjXPw2x6IZZJLjHVk= =hyph -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q4/146

oss-secXen Security Advisory 517 v2 (CVE-2026-79610) - grant-table: double version change race

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-79610 / XSA-517 version 2

grant-table: double version change race

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

XSA-501 was about issues with v1 -> v2 and v2 -> v1 changes racing certain other grant table operations. Sadly a v2 -> v1 -> v2 change has yet another effect which wasn't accounted for: During the first change, status pages would be freed. During the second change they would be allocated again. Hence across the full pair of change the addresses of the status pages may change, rendering stale previously calculated pointers into the status array.

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 (CONFIGGRANTTABLE turned off) are not vulnerable.

MITIGATION ==========

Using the "gnttab=max-ver:1" hypervisor command line option will avoid the vulnerability.

Using the "maxgrantversion=1" guest configuration option for guests will also avoid the vulnerability.

CREDITS =======

This issue was discovered by Claude Opus and diagnosed as a security issue 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.

xsa517.patch xen-unstable - Xen 4.17.x

$ sha256sum xsa517 0f114af84cd925f8bc69b26386e2e4a95a52f947bc400f961a9e1ba46c0a2e05 xsa517.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 -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmrOIlkMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZAGUH/3wERoCBP6lIwfFmIMiAcqVVctqz6/8OgplQEp8A inNRPR8Avx++0lt4AdERiNYy3xwxGAZzJsxYC3ipCaHvMwOmm11DiMX5yuhvefNw TJxWaWut2QmF0Vi0G4acvvlfslb9JA9quEgLDzF/2dMiyHzTL4xvdeJ5OR5zXAoD hexjk0DCSDcYRHnD0OautofMGTaBaGJVHz08uRNkz3gOxumAeKnxmfelF8QgnTb3 jRYIt5z+Kye8oXZ0uTVY86YR7YbuiaHAJx1YZzceyfaVjJzvS8ZsTFt2CXshcex8 33fw3iQnY9ImA/NC11y4OLt8F8nb+Ge2Cge98wBt8NPSoBc= =SAIu -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q4/145

oss-secXen Security Advisory 516 v2 (CVE-2026-79609) - x86: XPTI may bak on huge-memory systems

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-79609 / XSA-516 version 2

x86: XPTI may break on huge-memory systems

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

XPTI (Xen Page Table Isolation) was introduced to mitigate Meltdown (CVE-2017-5754, one aspect of XSA-254). This involves copying 64-bit PV guest page table entries from guest-chosen root page tables to the Xen- chosen one which is in actual use by hardware. To read the guest root page table, the directmap is used. PV guests, however, have a directmap which may not cover all memory; in particular this is the case if any memory extends beyond the 5 TiB (CONFIGBIGMEM=y: 3.5 TiB) address boundary.

IMPACT ======

A 64-bit PV guest may be able to elevate its privilege to that of the host. It is also possible for them to observe information pertaining to other guests, or to cause Denial of Service (DoS) affecting the entire host.

VULNERABLE SYSTEMS ==================

All versions of Xen with the XPTI work backported to are affected. In upstream these are Xen 4.7.5 and onwards, Xen 4.8.3 and onwards, Xen 4.9.2 and onwards, Xen 4.10.1 and onwards, and all major releases from 4.11 onwards.

Only 64-bit PV guests can leverage the vulnerability. HVM and PVH guests cannot leverage the vulnerability. 32-bit PV guests haven't been security supported anymore.

Only x86 systems are affected. Arm systems are not affected.

Only systems with RAM above the 5 TiB (CONFIGBIGMEM=y: 3.5 TiB) boundary are affected. Systems with no RAM above the 5 TiB (CONFIGBIGMEM=y: 3.5 TiB) boundary are not affected.

MITIGATION ==========

Not running 64-bit PV guests will avoid the vulnerability.

The "mem=" hypervisor command line option may be used to limit the amount of memory Xen is going to use. That would be "mem=5T" for the CONFIGBIGMEM=n case and "mem=3584G" for the CONFIGBIGMEM=y one.

CREDITS =======

This issue was discovered by George Dunlap.

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.

xsa516.patch xen-unstable - Xen 4.19.x xsa516-4.18.patch Xen 4.18.x xsa516-4.17.patch Xen 4.17.x

$ sha256sum xsa516 aff590335eed173a2f67375829a25682983cacf14ff170d25e636533552ecaa8 xsa516.patch 06b818ca56dff7ccc1f4842e9977a0eee283c516959980c85cf9d54d1c0abdb0 xsa516-4.17.patch 09d87137da9d5065227c808a1150cdbb878ae05785d6929de0754184313546fa xsa516-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 -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmrOIjwMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ0LoH/Ap814NnaDiHkPGqPWg0/N8gEJmPgUvSXXsjI8gb t+aLjuG3tI6j12jWtohBj67RiDAYWc3mAaqr7c9tb1Bi24IyenZIf8gAvkS72sUi Hl4WPCMcmgp0xM8s9b1peep5XTSVH1s+xDLGmBx21jXhoop1IJ5Na9VV2PcX50MJ assI8h4VE9xAYnMzMbd14IzbGXWylAZLdJYLGBoI06X7eZvPNPUvkktJaMqmSJgS IeJuUKK8pb5AFlefSxzcu007olRLhXxQrbkKXbwnyS+ZXI9r02hh8njPUTy8p/PG sLS5NNIHalXlxIOtQ20H+Hbi0n80nKn2T3ctjsKkmBGUioU= =KASN -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q4/144

oss-secXen Security Advisory 515 v2 (CVE-2026-79608) - x86/AMD: ineffectual Zenbleed workaround

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-79608 / XSA-515 version 2

x86/AMD: ineffectual Zenbleed workaround

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

The workaround for XSA-433 (Zenbleed, CVE-2023-20593) was later re-worked to better integrate with other manipulations of the same MSR. In this rework an inverted conditional was introduced, resulting in the workaround to not be applied when needed and vice versa.

For more details, see: http://xenbits.xen.org/xsa/advisory-433.html

IMPACT ======

An attacker can exploit this bug to read data from different contexts on the same core. Examples of such data includes key material, cypher and plaintext from the AES-NI instructions, or the contents of REP-MOVS instructions, commonly used to implement memcpy().

VULNERABLE SYSTEMS ==================

Xen versions 4.19.4 and onwards, 4.20.3 and onwards, 4.21.1 and onwards, and 4.22 are affected. Xen versions 4.18, minor versions 4.19.3 and earlier, minor versions 4.20.2 and earlier, and 4.21.0 are not affected.

The vulnerability can only be leveraged on systems running out-of-date microcode. Microcode fixing Zenbleed was published in late 2023. Updated firmware subseqeuent to this, or e.g. updated amd-ucode from linux-firmware (for the subset of CPUs covered by linux-firmware) are not vulnerable.

The original issue and hence the applicability of the workaround is specific to the AMD Zen2 microarchitecture. AMD do not believe that other microarchitectures are affected.

MITIGATION ==========

This issue can be mitigated by disabling AVX, either by booting Xen with cpuid=no-avx on the command line, or by specifying cpuid="host:avx=0" in the vm.cfg file of all untrusted VMs. However, this will come with a significant impact on the system and is not recommended for anyone able to deploy the microcode or patch described below.

CREDITS =======

This issue was discovered by Sashiko + Opus 5.0 and diagnosed as a security issue by George Dunlap.

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.

xsa515.patch xen-unstable - Xen 4.19.x

$ sha256sum xsa515 d54c5f5443209e523c1d1b456063d105792058d402513bc1e56246b5938de6d8 xsa515.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 altering exposure of AVX 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 -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmrOIhsMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZKrYIAIKTxPm+Rvb9K2SvRJoHgjFDGTG0OxXqWFDjPnUR DKTx/URFmXCFT4PCGuAearWnkw25x0e80TdNfCrdHxDJzENSCcmb+5iIuM8nUtgo hMwNON4YUWn0GhBe3fcgAdlmxwWfhIJZHWt0LDrZrO9Nr21hmgVhvzME2VtH0EkA Yafi6ZixVwheA48w2to1cBjx27J5XucmvFoMgSRfW40YhpCmWDLDMv1F0vwxioyy vWVrk7pfYEj8n/hiap2MoI/pTDD6PruF+lWsO1fzHFwZHcUPOU+rV/elfEAA027E rRVsxob58ljY1IH/sMYOmSm7OQaGjau0kS7vC9kXtm7lmBQ= =NxYd -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q4/143

Xen Project XenUnconditionally do TLB flushing ahead of page scrubbing

Risk 24

Severity

4.3

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

x86 PV guests can free memory pages while still keeping a stale TLB entry pointing to them. A TLB flush is only issued by Xen (if needed) when the page is re-used. Since it's possible for the page to be scrubbed ahead of the TLB flush, there's a window where a PV guest can modify an already scrubbed page.

First published (updated )

CVE-2026-79603

Xen Project Xenx86: DMs may cause mem leak by IRQ binding

Risk 39

Severity

6.5

Race Condition

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H

When guests are terminated, various pieces of cleanup need carrying out. The cleaning up of PCI devices which were assigned to guests, and the associated removal of tracking structures for IRQs used by the devices occurs relatively early in the process. Unfortunately after that point the guest about to be terminated could cause its device model (DM) to re-establish such tracking structures, by having it bind one or more IRQs anew. While some of those tracking structures would still be cleaned up later on, at least one would not be.

First published (updated )

CVE-2026-62437

oss-secXen Security Advisory 512 v3 (CVE-2026-79604) - oxenstod: Unbounded accumulation of watches

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-79604 / XSA-512 version 3

oxenstored: Unbounded accumulation of watches

UPDATES IN VERSION 3 ====================

Public release.

ISSUE DESCRIPTION =================

Oxenstored maintains two datastructures about watches; one global trie, and one hashtable tracked per domain. When a xenbus reconnect is requested, watches are not cleared out of the global trie.

IMPACT ======

A guest can cause unbounded memory usage in oxenstored. This can lead to a system-wide DoS.

VULNERABLE SYSTEMS ==================

All version of Xen from 4.6 onwards are vulnerable.

Only systems using the Ocaml Xenstored implementation are vulnerable. Systems using the C Xenstored implementation are not vulnerable.

MITIGATION ==========

There are no mitigations.

CREDITS =======

Found by Anthropic using agents to study the security of open-source projects, with Ada Logics validating and reporting.

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.

For xen.git oxenstored:

xsa512-?.patch xen-unstable - Xen 4.18.x xsa512-4.17-?.patch Xen 4.17.x

For xapi-project/oxenstored:

xsa512-oxenstored-?.patch oxenstored master

$ sha256sum xsa512 c4f92a3e032f853a85cbd43391b6fd6a2c8f6f4caeee49bec9bc97a5279ce9a3 xsa512-1.patch 2cc57079eda8f0db34885e8be242d736f590ae8094c60a044b55b4889e10392f xsa512-2.patch 16bfa30473d4ba67dea69f1915357ecbe4aefc3b10bfd413f0bd7a7d2cfe2a80 xsa512-4.17-1.patch 7c23fb0e64429db074d7ec4cf7ba6ba319b69d5f1d059aa848c19b9ce148244c xsa512-4.17-2.patch 28c6267057ccf3508eee92dd82a9726e6b0d616fd7cc3e7dcee9cbfd3b0b80f7 xsa512-oxenstored-1.patch 00b9df35d9cc3ee393385a65725a2a681e31b9e00c4d1d76e0441e284f005707 xsa512-oxenstored-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 -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmqf98gMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZk9kIAMqGI+5EVMLUd++EmpLqiTyGPcMYcDexca9XIpfJ Gx+DICPIRfRDCFtUG4jEeEDi8lmDvIKp5XXTNRkxyWF3uVKYDA5xCxekKOGmS40A p46pGzVVzGeSKdm2FfxEDDyuhhET5QrZLN98rJBcoL0/aX5sI4UoDR/FfdFemoAV BVrRG4WgQuBDa7+/t4jgZ8DysZbn/zmLoOtNIPVtaH5zvep0ehGQSnR8sAOEB+mV tmiW3kQoR1hxlOF/p1iVKLoBdOtJktwJ+Tk6OCCssS5TNGlGcpTs0KPukkXKwrem vYDYkHeUTf4rd3khUfCdW1S0Gc/3XSBtdL26VSj1xku5kMA= =6TLi -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q3/673

oss-secXen Security Advisory 511 v3 (CVE-2026-79603) - Unconditionally do TLB flushing ahead of page scrubbing

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-79603 / XSA-511 version 3

Unconditionally do TLB flushing ahead of page scrubbing

UPDATES IN VERSION 3 ====================

Public release.

ISSUE DESCRIPTION =================

x86 PV guests can free memory pages while still keeping a stale TLB entry pointing to them. A TLB flush is only issued by Xen (if needed) when the page is re-used. Since it's possible for the page to be scrubbed ahead of the TLB flush, there's a window where a PV guest can modify an already scrubbed page.

IMPACT ======

Deployments using xsm=silo scrub-domheap with the aim of not allowing the exchange of information amongst guests are not effective in the presence of PV guests.

VULNERABLE SYSTEMS ==================

All Xen versions from 4.13 onwards are vulnerable. Xen versions 4.12 and earlier are not vulnerable as they lack the scrub-domheap command line option.

Only x86 PV guests can exploit the vulnerability.

MITIGATION ==========

There is no known mitigation.

CREDITS =======

This issue was discovered by Roger Pau Monné of AMD.

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.

xsa511.patch xen-unstable - Xen 4.22.x xsa511-4.21.patch Xen 4.21.x xsa511-4.20.patch Xen 4.20.x xsa511-4.19.patch Xen 4.19.x xsa511-4.18.patch Xen 4.18.x - Xen 4.17.x

$ sha256sum xsa511 ba3731960983ef88836f96655f917abb25447eab69fda1d9cf7f4e8203138403 xsa511.patch c05a2d9fb391739a9ed39aa9247be264eb039bdac74f2db3b51e20199e6234cd xsa511-4.18.patch 9653110b3e82ea5c28185d436b22231f39d6e875712a7c9c6882d8cb1bd0d406 xsa511-4.19.patch 0a475b8622d867210346612c5f97a9c3b7b638de2704d51fbd86317b6b11a840 xsa511-4.20.patch 61aa358aef962a1e4dda3dd45cac7436e395362e9b5f9314ad3c60d39231cb97 xsa511-4.21.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/4UyVfoK9kFAmqf98YMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZf6EH/3BoQ+95hSDLUYJzmWNdjdqwYpyrWe1RaMcXWfuM DuvbkEd6SIrtkhEmO8ZHSiBm2g5v9/SyXrm0L4NZ2+LcZWbOAx0PK9D3DOjpIZk2 LpQJg75GPWLkBZ62vgZlCzcXa0opVNSrmnJvYimoHvdplMpFQOhd7Ve3988XCx1G Mb7tKeQ7IdgAW0P/gMTGpunGL9dF58N2d8H5qbp5695tneszzW1UtAVB+4BxlEuh WenQ1hJVtEWznRTYvaEJ7v6CYBoY7TmeYkpZviGhTj8cuTWguMNrKuSitPkRNJ+P OLIQ/pz3E6PGhJxXWw8BpjkDzHf9ETACu1g+sa+18z6/+1o= =/FMW -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q3/672

oss-secXen Security Advisory 510 v3 (CVE-2026-79602) - x86: improper handling of HVM emulation turn codes

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-79602 / XSA-510 version 3

x86: improper handling of HVM emulation return codes

UPDATES IN VERSION 3 ====================

Public release.

ISSUE DESCRIPTION =================

A guest with a PCI device assigned that has at least a BAR on the IO port space can trigger a BUG() in Xen.

IMPACT ======

Passing through a PCI device with at least one BAR in IO address space to unprivileged HVM guests can result in a Denial of Service (DoS) affecting the entire host.

VULNERABLE SYSTEMS ==================

Xen versions 4.6 and later are vulnerable. This is known to be the case with the fix for XSA-491, but it's possible the issue can also be triggered from other, non-analyzed paths.

Only x86 systems are vulnerable. Arm systems are not vulnerable.

Only HVM guests with a PCI device with IO BARs assigned can leverage the vulnerability.

MITIGATION ==========

There is no mitigation available.

CREDITS =======

This issue was discovered by Jiqian Chen of AMD and diagnosed as a security issue by Roger Pau Monné 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.

xsa510.patch xen-unstable - Xen 4.17.x

$ sha256sum xsa510 915cca4f0e6af998683a3551e5913d2489b23a697d5eab11358d4d8ffe0a0e55 xsa510.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/4UyVfoK9kFAmqf98UMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ3GEIALHxkeOzpl3/ctf8o9R89LFTfayDXMY6xGbUTsRk oiLIoKkYkZJPtiG6cY8YGRvzm/UYr+KpeMBsNtm0EcbZlPClGjkEc7JSSpMvcVps XTzRkIUhyOTfpKklhDQJynIIpMu8NkJBLvyVYDcY8fpeZ7yDykMkQ4RyvXT5A56r Vn18FJ401QqBO0+NTD0aCcasiLFpfrsh3AhPfKLIi7c3q0tIayyNBS8NBSNss+TF OJew3jWX7bWnAUlPl4b8EMm4gwK/7o6YJYW+NMCTNMJ/UdfvOJkkq9T8l/41FIXq ArtZrFpKWxsitNoXG7pJIyH/C5wBH2DFABzfqgNjkpzfqKw= =sVA/ -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q3/671

oss-secXen Security Advisory 509 v3 (CVE-2026-62437) - x86: DMs may cause mem leak by IRQ binding

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-62437 / XSA-509 version 3

x86: DMs may cause mem leak by IRQ binding

UPDATES IN VERSION 3 ====================

Public release.

ISSUE DESCRIPTION =================

When guests are terminated, various pieces of cleanup need carrying out. The cleaning up of PCI devices which were assigned to guests, and the associated removal of tracking structures for IRQs used by the devices occurs relatively early in the process. Unfortunately after that point the guest about to be terminated could cause its device model (DM) to re-establish such tracking structures, by having it bind one or more IRQs anew. While some of those tracking structures would still be cleaned up later on, at least one would not be.

IMPACT ======

A HVM guest with one or more PCI devices assigned can cause a memory leak in the hypervisor, possibly leading to Denial of Service (DoS) of the entire host.

VULNERABLE SYSTEMS ==================

All Xen versions from at least 3.2 onwards are affected. Older versions have not been inspected.

Only HVM guests with assigned PCI devices can leverage the vulnerability.

MITIGATION ==========

Running only PV or PVH guests will avoid the vulnerability.

Running only HVM guests without passing through PCI devices to them will also avoid the vulnerability.

CREDITS =======

This issue was discovered by Jan Beulich of SUSE.

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.

xsa509.patch xen-unstable - Xen 4.17.x

$ sha256sum xsa509 1e027737afa753f3498102ceac4abe62b11a49cfa019f25bb19728a7931f9096 xsa509.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.

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 removing/replacing of pass-through devices or their replacement by emulated devices 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 -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmqf970MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ6hYIAIDrF44cxjA9slR5fXYXpQvlGHE8wvTr5F5vNdXO JlB8yMQjdUPMfSLX0oMPapUwLE/UzFFA/MTXORrK6nj3TbRRHLqF9e9upL6e3QHH RrV4m2R5OSVjD6PG+T+e24ES5I4SLUTWv9i4vQZPzY54rjMtZ4d53DZk2eQ5v9kj ozYgQzwk5vMvRhnPv6MVdcBr2EfQ274+XxMKioMBZaFuv+zeomaQTAiok8gXhotX 6twiuhuhvMOtF2FA8V1WkKwUqw5NKm/plv54d8RRB/XNdxPe/8bxY0NlLGgRpMf3 cjSqsuhpEgpY3Vh62v3S0fAtExnWppdb/glJE+g4MZGzC7s= =J7JJ -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q3/670

Xen Project XenPoD: Don't try to reclaim special pages

Risk 28

Severity

5.3

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

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.

First published (updated )

CVE-2026-62434

Xen Project Xencorrect buffer checks for DM_OP hypercalls

Risk 54

Severity

7.3

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

Parts of the DMOP 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.

First published (updated )

CVE-2026-62433

Xen Project XenvNUMA domain cleanup may race other operations

Risk 40

Severity

6.5

Race Condition

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

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.

First published (updated )

CVE-2026-62429

Xen Project Xensysctl and platform-op locks open to abuse

Risk 83

Severity

8.8

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]

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.

First published (updated )

CVE-2026-62427

Xen Project XenvIRQ event channel binding may break Xenstore

Risk 46

Severity

7.5

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Xenstore, to have an up-to-date picture of the entire system, wants to know of domains appearing and disappearing. To make this more robust, a new XENDOMCTLgetdomainstate was introduced. The management of the bitmap underlying that operation is tied into the binding of the VIRQDOMEXC virtual IRQ. Unfortunately an error path there would tear down the bitmap even in cases when it wasn't set up. Unprivileged domains can trigger that error path.

First published (updated )

CVE-2026-42492

oss-secXen Security Advisory 508 v2 - pygrub is only supported in de-privileged mode

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

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 bootloaderrestrict 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 -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomsAMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZLhoH/38QGcVs3Xc3KuskdvBx57IV/vW9XjNlVYSngmdm lKzXTZhjrecrPZvwBbhuqOBXkaFQSL17+lLVK3xRAzv2dd5hn2PqXkMj06JSwcrh haXN/JWUDwQtmJuLfGNkQ9P1W27oMXZ3pBGhv1SsEfD0mNiyC7ZZKizU291usZbF 6JMUGNUmQ1Dyom2CiylmJGmrNrHzKdfNqURc+DoSOctpS9vbT0U0xLtKYvbVr3cj 7DuITo1/gS/3pxiUw/7E5uR7zPusBGISP1ir5rBqTkgoMf2tJkt7tfygqJtrqnkU BaUt0ZCo7NBKg71o0AESZIdO3Ddg2QD6xrymtI0BVqa0n1E= =9mkq -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q3/312

oss-secXen Security Advisory 507 v2 (CVE-2026-62434) - PoD: Don't try to claim special pages

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

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 -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomr4MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ+04H/i3UMWbGcPG2kp978waMmF3Gtfb/r8mw3UBzVGCi cIOBWf/FizjWu54SQEQtjwYPfi0nKftFN1UPqAGs+OUtyiZ8EcPL5x9i7arrqA2T uGfpCTb3NtFmacBbrpGnqkNahMtSLWtE8aSVEQhLxvZcLTPB6OPzIi/MVPGyA7jl /LSGWs4vd99Y8ZvAN20rhxaEAjYynfd7N4tXn38EoW9WiQBuPZ5eNzsbieah8PEo Ajntyx774ipvtYYStA4fhsLwO+6LyqH7okDR1g8Xkq6IVrOshP194mxnsuEfcMIO 4TCkWbzhmspfxQ1E2aW2VVPzIC2X2b+i8JieUK/z3mmrRSU= =AfG5 -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q3/311

oss-secXen Security Advisory 506 v2 (CVE-2026-62433) - corct buffer checks for DM_OP hypercalls

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-62433 / XSA-506 version 2

correct buffer checks for DMOP hypercalls

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

Parts of the DMOP 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 -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomrwMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZNF4H/0c6JMsivAWWDIQ920Bwh7EEOKhMv3nGIrBqrN8/ TGKJNNoNQinhoQv9fnqwsHaiC8e49PNUJqTpEN8/o/b0obnl4Tw2JyUXFY1bZyaz XNS85rkrUc0+Ue/Ka2464mmQ826TJXfaXG9CZYlC5cO/JtzX65ecMW4H7ju2tdnt c9xK+I5kIQPwUwy3HUMrKFvWi+JIvpCzhuHYDH2iJDecmk42pOmnKtS54q6YO15n c4xdn7aNyeECKQw4qUcjKC7zKRgrqFu5J3BlvXauZOkJCL50PK+OpWK6QV+fRNGy N7dnY5w+1BMVrHywZI5iy8WqZtJoi6TOO1Gl0WcB07/vvJk= =APkr -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q3/310

oss-secXen Security Advisory 505 v2 (CVE-2026-62432) - evtchn: Race between FIFO expand and set

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

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 EVTCHNOPexpandarray hypercall checks for whether FIFO event channels are enabled, but without holding the correct lock. It can race with EVTCHNOPreset, 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 -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomrsMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ5H8IAMKtDfTsBJaoOosFHEU0Gyv96fP98D89URo21RrD V+Lpd9CTatYuTnz53gztlUa7s2/ARYl488bNURwPTdTjSEdJBbFQKrEyAZsryTyh hiIJF7AhQf8LsY3qk2xuJ+/tKc720WK/zsUGVRz6Jhf9W90g5wBhIM1RAhfy7H2t Zn74wXDi4dsMLQg6VivzRq+y+XJfZKR6qoKztiDHk0DBobmJzQFF2cfkiiWDRW9l NuvLxKjsPyS4K+Jcm9k65RzmWfDprxmL/63VDAt0W8dSAe+u1zyDh/aT+OFK5R1g c6CwdjquY4hhSYhwix4TW18LRlY0NA/pqn3FmhLQl3XZmfU= =z4Qy -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q3/309

oss-secXen Security Advisory 504 v2 (CVE-2026-62431) - Viridian STIMER division by zero

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

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 -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomroMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZiF4H+QFl08pzXWh5Zd2uOlbjYCaQMoDFeWSGCAkCcG8z PlKv4yVLPwxUB0W5cPVV61M/fFDgihZh0usNZ/xm5aTt0uhPE31kXItsYRRLPpmg zbV5OgUgIJxeAABML030lNjlAyLBpVculHAWbyFZdMh/xf0bQc1ty8U/xQDLU+IE cohmtH8v6WvK2PxTA8nNj39EB9rUcz1gYInLh2QltW14di7+FUHGISxiIr/eNcUv 9d/at8ESSH1WNeSRSr+sbE0dMRxAQgoMa93GvU7sEvuZtdwOnnET8l1nVN/84kXM sCMq6mjgVDUmSNOH2aBXxewimjp9DV0BLkmliqHrHDKer3s= =intH -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q3/308

oss-secXen Security Advisory 502 v3 (CVE-2026-62429) - vNUMA domain cleanup may race other operations

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

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 -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomrQMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ58sH/2CogHDnmyLVcaB68ySxCnCZI5qNt0VonyH4n3s0 Ef4H74nwh3osLXrvkcnXvbrH4hqDKI3MtydScfHc5dpa1rQHXO8utHxZtGUU+CSv A1nSYD42pu96V5xvTXO+xK5sCZoBREgUNS2TGCE02dkwXdngsCWnAPFn1BQi7wsG LJWuzurlSRSc28PPuIEaKJM+eiyG88ep5fADrLycVPvltqd6bktEE1Xa82h5iSYd 9K7KTEDT9Kc0HZEg4x0h2OBwVqGdKF+8FHDNCEtpiwtE2Ao6OycTVzGNX7f+fq4/ CeQjI8I94j/r1zVPtuGBHNVkUdgrCIe36156RC7f1LFy0JM= =7hf1 -----END PGP SIGNATURE-----

First published (updated )

https://seclists.org/oss-sec/2026/q3/306

oss-secXen Security Advisory 501 v4 (CVE-2026-62435,CVE-2026-62436) - grant-table: version change racing with other operations

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

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 (CONFIGGRANTTABLE turned off) are not vulnerable.

MITIGATION ==========

Using the "gnttab=max-ver:1" hypervisor command line option will avoid the vulnerability.

Using the "maxgrantversion=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 $