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.

AMD: CVE-2025-54518 CPU OP Cache Corruption

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.

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

Xen Security Advisory CVE-2026-79605,CVE-2026-79606 / XSA-513 version 3

Out-of-bounds accesses in Tapdisk

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

Public release.

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

Tapdisk is a userspace xen-blkback implementation used by the XAPI toolstack. Several bounds checks have been found to be incorrect.

There is no upper bounds check for blkif->lastsect. Passing a value larger than 7 will result in a read or write beyond the mapped grant.

This is CVE-2026-79605.

The gcopysegs[] object has incorrect bounds checks on it. Passing nrsegments between 12 and 32 will corrupt adjacent memory.

This is CVE-2026-79606.

IMPACT ======

A malicious guest can obtain code execution within the tapdisk process running in dom0. Tapdisk normally runs as root.

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

All versions of tapdisk are vulnerable.

MITIGATION ==========

There are no mitigations.

CREDITS =======

Found by Jihwan Yoon of NAVER Cloud, and reported via XenServer.

RESOLUTION ==========

Applying the appropriate attached patchs resolves this issue.

xsa513-?.patch blktap master

$ sha256sum xsa513 41e5f1929a7acbe83820ee0b359f9558120222d32442ea4fb5a6eee0bf937bf1 xsa513-1.patch a5af5a73d2ede5124735213e4974f1aeff7f8118dfbacd52fbb03168fe96c6af xsa513-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/4UyVfoK9kFAmqf98kMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZiuMIAIaNhPYKG/UeGc1JV70GEcyqS4d6NNlNBY0qtuGl qVQ8LRVBReqRk0aS0hNDI7txFRsZ18ENteBKG/JaXD4mj5rylpnKdl7y8suTFrGi QuFk1EyYBrud5gtpwW8sq4GKQLf5hoAIIUDGX4qmEC+blRuHTagUIHNwehrkRB+d 38UxmWQR2ppgBSsCJlclMJKSm1nWo04Qx/Nm3Aoc0og0hv+/UkdkDShTGrP/nutb /r4yywz6LaqdCl7Te1ULx6sRVl1MIxtDqcvsRajqKc9nV56RAgrj3moIJRXRusW9 YqZxuUw8HJkhpisOlj6A/N16f+G7bxZwb3FEZBKuNGvM6lQ= =oXUQ -----END PGP SIGNATURE-----

-----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-----

-----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-----

-----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-----

-----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-----

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.

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.

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.

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.

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.

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.

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

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.

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

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.

[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.

[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.

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

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.

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

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.

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

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.

-----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-----

-----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-----

-----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-----

-----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-----

-----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-----

-----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-----

-----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 $

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/4UyVfoK9kFAmpomrIMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZc98H/0wOjr4aa/IMxNH41B8p6vx1ayiBDvTV8qWgmjf9 AyjNGWG5sAjViMDjtFMUE/CeOeoby+gPRfzop9L7cjlHzy8+y/5s9oRUzC+0VIDq 1V5SBbD0XzhqujoLj5LBF0M1a/EyAJzYeVIV3t1DL6yFAz9YRpUGz6pNAwnF0dui bfNZcT2K0+BV0YHUQMrEkAUd+PV/mObG8AiVDS8j9BU8sGN4m1Wx2hsYzqYBCXpK T3lT8dG9qaYcnlH+m9jfWFIE2Srr9a2rLdCMs4dHY1CB/FmZLRrWe304yFuQntET OGiyZWW86cjmANEKAjrYHSD/CRa81gBqdxiAH/N13zBxZ7I= =VVHS -----END PGP SIGNATURE-----