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

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

Xen Security Advisory CVE-2025-54518 / XSA-490

x86: CPU Opcode Cache corruption

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

AMD have disclosed a potential vulnerability in certain CPUs which can cause instructions to execute at a higher privilege.

For more information, see: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7052.html

IMPACT ======

Code of any privilege could escalate to a higher privilege, including userspace to kernel, and guest to host.

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

Systems running all versions of Xen are affected.

Only AMD Fam17h CPUs (Zen2 microarchitecture) are believed to be vulnerable. Other AMD CPUs and CPUs from other manufacturers are not known to be affected.

MITIGATION ==========

There are no mitigations.

RESOLUTION ==========

Applying the appropriate attached patch resolves this issue.

For Xen 4.17, patch 1 is a backport of a change which only went back as far as 4.18 under normal bugfix rules, but which is tightly texturally coupled with the XSA-940 fix. It is possible to rework patch 2 to avoid patch 1, but a number of Xen-focused downstreams already have patch 1 backported, and those without patch 1 really ought to take it. So, while this is slightly abnormal for an XSA, it is believed to be in the best interest of everyone with a 4.17 based Xen.

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.

xsa490.patch xen-unstable xsa490-4.21.patch Xen 4.21.x - Xen 4.18.x xsa490-4.17-?.patch Xen 4.17.x

$ sha256sum xsa490 7c256d3384bf640d171ae2f18930c193a72bbdd92ebeb8942e58634dd7b27439 xsa490.patch 4d64d95937630f2147bb69d0d0ff24fc7d97efd48e376d882265662f93886ec7 xsa490-4.17-1.patch 6c717a5bd914088463c74b89893672388848a2222165478aed63b6c2a4151e28 xsa490-4.17-2.patch 1e397550a542bc0957bf93a6e6f01ffcdfe8f005697a505c62ec6120a72d3f90 xsa490-4.21.patch $ -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmoDTuQMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZn38H/2xujQ3YDEsE2U8RiH/6M1yVxnATlCEqEPBxIcVX h6W4QMzlFw/IXZBi6twduuzMME2uX6eKWCbE9riw2v4lybgNYMxV20oW86LhjLwr uL1NHJ3Fop1IuRy+po20jmT9sPfpieHU9zGmFvgd/k91gSZ1b/5G8k36MtgODL0j 4Svsdo3LYSvULQn5EymjO/t57ZZIDBWj5Od7aBbPuGkQKtW6+/UCE0JnrzOtP+Di 0Y5bBSUhwrMh0h32AV/w2nwvFQN/EeyakfjDWQc1ST6wHzFMLSo2kaY40TZ6C+T8 RnN646ouPizmiSDu2G/dMrLJ5kc3PFqQvN3JRI4dyf075yg= =Dclq -----END PGP SIGNATURE-----

The adjustments made for XSA-379 as well as those subsequently becoming XSA-387 still left a race window, when a HVM or PVH guest does a grant table version change from v2 to v1 in parallel with mapping the status page(s) via XENMEMaddtophysmap. Some of the status pages may then be freed while mappings of them would still be inserted into the guest's secondary (P2M) page tables.

Any guest can cause xenstored to crash by issuing a XSRESETWATCHES command within a transaction due to an assert() triggering.

In case xenstored was built with NDEBUG #defined nothing bad will happen, as assert() is doing nothing in this case. Note that the default is not to define NDEBUG for xenstored builds even in release builds of Xen.

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

Xen Security Advisory CVE-2026-23556 / XSA-483 version 2

oxenstored keeps quota related use counts across domain destruction

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

Public release.

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

When oxenstored is tearing a domain down, the node data is cleaned up but the usage counts are leaked.

When the domain ID is eventually reused, the new domain can create fewer nodes before beeing deemed to be over quota.

IMPACT ======

Over an extended period of time, new domains will be able to create fewer and fewer nodes in xenstored, until they are eventually unable to operate at all.

A buggy or malicious domain can speed this process up by deliberately hitting it's quota, and then rebooting.

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

All versions of Xen containing the XSA-419 fixes are vulnerable.

Only systems configured to use oxenstored (Ocaml xenstored) are vulnerable. Systems configured to xenstored (C xenstored) are not vulnerable.

MITIGATION ==========

Performing a xenstore live update mitigates the issue.

CREDITS =======

This issue was discovered by Andrii Sultanov 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.

xsa483.patch xen-unstable - Xen 4.18.x xsa483-4.17.patch Xen 4.17.x xsa483-xapi.patch XAPI oxenstored

$ sha256sum xsa483 4be3acc57dcd5e2719cab165729879757a1915c33b848a37623dd4a5f1157746 xsa483.patch 389b0411d855894adff6f640dcbd3358adc6d4cb9ddeedbcb9cb2c345af67d51 xsa483-4.17.patch ec191a1e158eddd22bfbd764f26f6b6a0b75b9fe0a223dc66da1c4a16ef73122 xsa483-xapi.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/4UyVfoK9kFAmnwoPIMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZM8EH/iXC6hLQHAVLeRCfUEZ1ncM7029KPyRxLIOlthCS cAyMNjyVSckGMRgKvYWCpl/fN1v/2yv3olIIR9wtncaq8Q+iMkwOsw1P46fmsh3J 40pK6PnaP1/kRrua1ZANlUc8YUhWG8fE2ADPHCIo57qbO1fXVUEWARdgU5gYIkF4 Kz+dvkpEEiTdRe24zqfn9Bv4lDsihfq3B9zecEuqMj3L88FrMP9VfBJZMbx9N/Pb TUE/FltETdWqMLeIyb7r3P5OPrLRYk6ebgrX96Pb3f0d1/OC8E4Me3RNvGoArmOI f8R0M/zly0lmoJspJFtI2C7BdUIKB/59z/Sz2YC706AJBO0= =mbDG -----END PGP SIGNATURE-----

Any guest issuing a Xenstore command accessing a node using the (illegal) node path "/local/domain/", will crash xenstored due to a clobbered error indicator in xenstored when verifying the node path.

Note that the crash is forced via a failing assert() statement in xenstored. In case xenstored is being built with NDEBUG #defined, an unprivileged guest trying to access the node path "/local/domain/" will result in it no longer being serviced by xenstored, other guests (including dom0) will still be serviced, but xenstored will use up all cpu time it can get.

The Intel EPT paging code uses an optimization to defer flushing of any cached EPT state until the p2m lock is dropped, so that multiple modifications done under the same locked region only issue a single flush.

Freeing of paging structures however is not deferred until the flushing is done, and can result in freed pages transiently being present in cached state. Such stale entries can point to memory ranges not owned by the guest, thus allowing access to unintended memory regions.

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

Xen Security Advisory CVE-2026-23554 / XSA-480 version 3

Use after free of paging structures in EPT

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

Public release.

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

The Intel EPT paging code uses an optimization to defer flushing of any cached EPT state until the p2m lock is dropped, so that multiple modifications done under the same locked region only issue a single flush.

Freeing of paging structures however is not deferred until the flushing is done, and can result in freed pages transiently being present in cached state. Such stale entries can point to memory ranges not owned by the guest, thus allowing access to unintended memory regions.

IMPACT ======

Privilege escalation, Denial of Service (DoS) affecting the entire host, and information leaks.

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

Xen 4.17 and onwards are vulnerable. Xen 4.16 and older are not vulnerable.

Only x86 Intel systems with EPT support are vulnerable.

Only x86 HVM/PVH guests using HAP can leverage the vulnerability on affected systems.

MITIGATION ==========

There are no mitigations.

CREDITS =======

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

RESOLUTION ==========

Applying the attached patch resolves this issue.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa480.patch xen-unstable - Xen 4.17.x

$ sha256sum xsa480 578f8fec3f34656e085419f6376d43987ffd6ed32e067b4024d3c83ce03a5901 xsa480.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmm5Q1MMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZKDgH/jDFwjlPNV0IQor3c5j9D7L++i5dFugypaF5OI+Q nboD7VEe6y1KexRsPa/a7UAvuabgGdudeS18IS3W34/9TZILZRITo9s3IgEnTfQR qqFlCTxymFuCn8Iptq8SJh37fG3nc9OJ/v28s+0+X9ERnjjjVcjhwcbQ5gQSpKU0 7fAe+IpsO3YOMGb3fgpjhCWMjh9UTHnKOBmObNeDGZ3sXgh8+FYkt6snRs0bYwW4 IcGpmEEgK+Id6n/0sG07Ntntb02EcCz3Vl8G0OflNQj/XOxHBuXbkFc36K2vpUDp dGrzGkIznA00Oz2UNlZrSrMWAQtKuHbB9+H2tU+7BNq+ag8= =RFix -----END PGP SIGNATURE-----

In the context switch logic Xen attempts to skip an IBPB in the case of a vCPU returning to a CPU on which it was the previous vCPU to run. While safe for Xen's isolation between vCPUs, this prevents the guest kernel correctly isolating between tasks. Consider:

1) vCPU runs on CPU A, running task 1. 2) vCPU moves to CPU B, idle gets scheduled on A. Xen skips IBPB. 3) On CPU B, guest kernel switches from task 1 to 2, issuing IBPB. 4) vCPU moves back to CPU A. Xen skips IBPB again.

Now, task 2 is running on CPU A with task 1's training still in the BTB.

Shadow mode tracing code uses a set of per-CPU variables to avoid cumbersome parameter passing. Some of these variables are written to with guest controlled data, of guest controllable size. That size can be larger than the variable, and bounding of the writes was missing.

When passing through PCI devices, the detach logic in libxl won't remove access permissions to any 64bit memory BARs the device might have. As a result a domain can still have access any 64bit memory BAR when such device is no longer assigned to the domain.

For PV domains the permission leak allows the domain itself to map the memory in the page-tables. For HVM it would require a compromised device model or stubdomain to map the leaked memory into the HVM domain p2m.

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

Some Viridian hypercalls can specify a mask of vCPU IDs as an input, in one of three formats. Xen has boundary checking bugs with all three formats, which can cause out-of-bounds reads and writes while processing the inputs.

CVE-2025-58147. Hypercalls using the HVVPSET Sparse format can cause vpmaskset() to write out of bounds when converting the bitmap to Xen's format.

CVE-2025-58148. Hypercalls using any input format can cause sendipi() to read d->vcpu[] out-of-bounds, and operate on a wild vCPU pointer.

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

Some Viridian hypercalls can specify a mask of vCPU IDs as an input, in one of three formats. Xen has boundary checking bugs with all three formats, which can cause out-of-bounds reads and writes while processing the inputs.

CVE-2025-58147. Hypercalls using the HVVPSET Sparse format can cause vpmaskset() to write out of bounds when converting the bitmap to Xen's format.

CVE-2025-58148. Hypercalls using any input format can cause sendipi() to read d->vcpu[] out-of-bounds, and operate on a wild vCPU pointer.

Certain instructions need intercepting and emulating by Xen. In some cases Xen emulates the instruction by replaying it, using an executable stub. Some instructions may raise an exception, which is supposed to be handled gracefully. Certain replayed instructions have additional logic to set up and recover the changes to the arithmetic flags.

For replayed instructions where the flags recovery logic is used, the metadata for exception handling was incorrect, preventing Xen from handling the the exception gracefully, treating it as fatal instead.

A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.

When setting up interrupt remapping for legacy PCI(-X) devices, including PCI(-X) bridges, a lookup of the upstream bridge is required. This lookup, itself involving acquiring of a lock, is done in a context where acquiring that lock is unsafe. This can lead to a deadlock.

PVH guests have their ACPI tables constructed by the toolstack. The construction involves building the tables in local memory, which are then copied into guest memory. While actually used parts of the local memory are filled in correctly, excess space that is being allocated is left with its prior contents.

In x86's APIC (Advanced Programmable Interrupt Controller) architecture, error conditions are reported in a status register. Furthermore, the OS can opt to receive an interrupt when a new error occurs.

It is possible to configure the error interrupt with an illegal vector, which generates an error when an error interrupt is raised.

This case causes Xen to recurse through vlapicerror(). The recursion itself is bounded; errors accumulate in the the status register and only generate an interrupt when a new status bit becomes set.

However, the lock protecting this state in Xen will try to be taken recursively, and deadlock.

When multiple devices share resources and one of them is to be passed through to a guest, security of the entire system and of respective guests individually cannot really be guaranteed without knowing internals of any of the involved guests. Therefore such a configuration cannot really be security-supported, yet making that explicit was so far missing.

Resources the sharing of which is known to be problematic include, but are not limited to - - PCI Base Address Registers (BARs) of multiple devices mapping to the same page (4k on x86), - - INTx lines.

Certain PCI devices in a system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, "RMRR") for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as legacy USB emulation.

Since the precise purpose of these regions is unknown, once a device associated with such a region is active, the mappings of these regions need to remain continuouly accessible by the device. In the logic establishing these mappings, error handling was flawed, resulting in such mappings to potentially remain in place when they should have been removed again. Respective guests would then gain access to memory regions which they aren't supposed to have access to.

An optional feature of PCI MSI called "Multiple Message" allows a device to use multiple consecutive interrupt vectors. Unlike for MSI-X, the setting up of these consecutive vectors needs to happen all in one go. In this handling an error path could be taken in different situations, with or without a particular lock held. This error path wrongly releases the lock even when it is not currently held.

Because of a logical error in XSA-407 (Branch Type Confusion), the mitigation is not applied properly when it is intended to be used. XSA-434 (Speculative Return Stack Overflow) uses the same infrastructure, so is equally impacted.

For more details, see: https://xenbits.xen.org/xsa/advisory-407.html https://xenbits.xen.org/xsa/advisory-434.html

Unlike 32-bit PV guests, HVM guests may switch freely between 64-bit and other modes. This in particular means that they may set registers used to pass 32-bit-mode hypercall arguments to values outside of the range 32-bit code would be able to set them to.

When processing of hypercalls takes a considerable amount of time, the hypervisor may choose to invoke a hypercall continuation. Doing so involves putting (perhaps updated) hypercall arguments in respective registers. For guests not running in 64-bit mode this further involves a certain amount of translation of the values.

Unfortunately internal sanity checking of these translated values assumes high halves of registers to always be clear when invoking a hypercall. When this is found not to be the case, it triggers a consistency check in the hypervisor and causes a crash.

Incorrect placement of a preprocessor directive in source code results in logic that doesn't operate as intended when support for HVM guests is compiled out of Xen.

PCI devices can make use of a functionality called phantom functions, that when enabled allows the device to generate requests using the IDs of functions that are otherwise unpopulated. This allows a device to extend the number of outstanding requests.

Such phantom functions need an IOMMU context setup, but failure to setup the context is not fatal when the device is assigned. Not failing device assignment when such failure happens can lead to the primary device being assigned to a guest, while some of the phantom functions are assigned to a different domain.

Gather Date Sampling (GDS) is a transient execution side channel vulnerability affecting certain Intel processor. In this flaw, a local attack using gather instruction (load from memory) may infer stale data from previously used vector registers on the same physical core.

AMD Ryzen, Gen AMD EPYC Processors could allow a local authenticated attacker to obtain sensitive information, caused by a use-after-free flaw in the vzeroupper instruction. By conducting a cache timing attack using a specially crafted application, an attacker could exploit this vulnerability to obtain sensitive data used by other processes, such as passwords and encryption keys, at a rate of 30KB/sec from each CPU core.

The AdSanity plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the 'ajaxupload' function in versions up to, and including, 1.8.1. This makes it possible for authenticated attackers with Contributor+ level privileges to upload arbitrary files on the affected sites server which makes remote code execution possible.

Xenstore: Guests can create orphaned Xenstore nodes By creating multiple nodes inside a transaction resulting in an error, a malicious guest can create orphaned nodes in the Xenstore data base, as the cleanup after the error will not remove all nodes already created. When the transaction is committed after this situation, nodes without a valid parent can be made permanent in the data base.

Xenstore: guests can let run xenstored out of memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Malicious guests can cause xenstored to allocate vast amounts of memory, eventually resulting in a Denial of Service (DoS) of xenstored. There are multiple ways how guests can cause large memory allocations in xenstored: - - by issuing new requests to xenstored without reading the responses, causing the responses to be buffered in memory - - by causing large number of watch events to be generated via setting up multiple xenstore watches and then e.g. deleting many xenstore nodes below the watched path - - by creating as many nodes as allowed with the maximum allowed size and path length in as many transactions as possible - - by accessing many nodes inside a transaction