[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] XAPI can configure different users with different roles, using Role Based Access Control. For more details, see:
https://docs.xenserver.com/en-us/xencenter/current-release/rbac-overview.html#rbac-roles
The pool-admin role is fully privileged. Notably, users with this role can also SSH into the host as root.
The other administrator roles are pool-operator, vm-power-admin and vm-admin, each of which are authorised to configure and manage various aspects of the system.
Some settings are inadequately restricted, and can be set by a lower privilege of administrator than expected.
CVE-2026-23559: A vm-admin can set VBD.otherconfig:backend-local and turn arbitrary files in dom0 into VDIs (virtual disks) and give said disks to a VM they control. This is an arbitrary read and/or modify of files in dom0.
CVE-2026-23560: A vm-admin can set VM.other-config:issystemdomain and mark a VM as a system domain. System domains are ignored and left running during certain other host/pool operations, and may be hidden from view in tooling.
CVE-2026-23561: A vm-admin can set VM.otherconfig:storagedriverdomain and mark a VM as the storage domain for a particular host storage connection (PBD). Shutting down the VM can cause the PBD to be erroneously marked as unplugged when it is not.
CVE-2026-23562: Configuration of PCI passthrough is normally restricted to the pool-admin role. However one API was missing this check, allowing a vm-admin access to unintended host hardware.
CVE-2026-42486: A vm-admin can set the VM.platform:hvmserial parameter, which should be restricted to the pool-admin role, as it can allow arbitrary dom0 file write.
-----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-----
For a brief summary of Xapi terminology, see:
https://xapi-project.github.io/xen-api/overview.html#object-model-overview
Xapi contains functionality to backup and restore metadata about Virtual Machines and Storage Repositories (SRs).
The metadata itself is stored in a Virtual Disk Image (VDI) inside an SR. This is used for two purposes; a general backup of metadata (e.g. to recover from a host failure if the filer is still good), and Portable SRs (e.g. using an external hard drive to move VMs to another host).
Metadata is only restored as an explicit administrator action, but occurs in cases where the host has no information about the SR, and must locate the metadata VDI in order to retrieve the metadata.
The metadata VDI is located by searching (in UUID alphanumeric order) each VDI, mounting it, and seeing if there is a suitable metadata file present. The first matching VDI is deemed to be the metadata VDI, and is restored from.
In the general case, the content of VDIs are controlled by the VM owner, and should not be trusted by the host administrator.
A malicious guest can manipulate its disk to appear to be a metadata backup.
A guest cannot choose the UUIDs of its VDIs, but a guest with one disk has a 50% chance of sorting ahead of the legitimate metadata backup. A guest with two disks has a 75% chance, etc.
Closing of an event channel in the Linux kernel can result in a deadlock. This happens when the close is being performed in parallel to an unrelated Xen console action and the handling of a Xen console interrupt in an unprivileged guest.
The closing of an event channel is e.g. triggered by removal of a paravirtual device on the other side. As this action will cause console messages to be issued on the other side quite often, the chance of triggering the deadlock is not neglectable.
Note that 32-bit Arm-guests are not affected, as the 32-bit Linux kernel on Arm doesn't use queued-RW-locks, which are required to trigger the issue (on Arm32 a waiting writer doesn't block further readers to get the lock).
Last updated 25 April 2025
The Ocaml xenstored implementation (oxenstored) in Xen 4.1.x, 4.2.x, and 4.3.x allows local guest domains to cause a denial of service (domain shutdown) via a large message reply.
The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in "standard" mode. Locking involved there has an unusual discipline, leaving a lock acquired past the return from the function that acquired it. This behavior results in a problem when emulating an instruction with two memory accesses, both of which touch VGA memory (plus some further constraints which aren't relevant here). When emulating the 2nd access, the lock that is already being held would be attempted to be re-acquired, resulting in a deadlock.
This deadlock was already found when the code was first introduced, but was analysed incorrectly and the fix was incomplete. Analysis in light of the new finding cannot find a way to make the existing locking discipline work.
In staging, this logic has all been removed because it was discovered to be accidentally disabled since Xen 4.7. Therefore, we are fixing the locking problem by backporting the removal of most of the feature. Note that even with the feature disabled, the lock would still be acquired for any accesses to the VGA MMIO region.
Incomplete cleanup in specific special register read operations for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
It was found that a malicious HVM guest administrator can cause DoS, specifically prevent use of physical CPU for significant, perhaps indefinite period. When a benign exception occurs while delivering another benign exception, it is architecturally specified that these would be delivered sequentially. There are, however, cases where this results in an infinite loop inside the CPU, which (in the virtualized case) can be broken only by intercepting delivery of the respective exception.
When a guest sets up a hardware breakpoint covering a data structure involved in delivering #DB (Debug Exception), upon completion of the delivery of the first exception another #DB will need to be delivered. The effects slightly differ depending on further guest characteristics:
Guests running in 32-bit mode would be expected to sooner or later encounter another fault due to the stack pointer decreasing during each iteration of the loop. The most likely case would be #PF (Page Fault) due to running into unmapped virtual space. However, an infinite loop cannot be excluded (e.g. when the guest is running with paging disabled).
Guests running in long mode, but not using the IST (Interrupt Stack Table) feature for the IDT entry corresponding to #DB would behave similarly to guests running in 32-bit mode, just that the larger virtual address space allows for a much longer loop. The loop can't, however, be infinite, as eventually the stack pointer would move into non-canonical address space, causing #SS (Stack Fault) instead.
Guests running in long mode and using the IST for the IDT entry corresponding to #DB would enter an infinite loop, as the stack pointer wouldn't change between #DB instances.
If a host watchdog (Xen or dom0) is in use, this can lead to a watchdog timeout and consequently a reboot of the host. If another, innocent, guest, is configured with a watchdog, this issue can lead to a reboot of such a guest.
A privileged user inside guest could use this flaw to crash the host kernel resulting in DoS.
For KVM virtualisation, it only affects the AMD processor support, as for Intel it already intercepts the #DB exception.
Upstream KVM patch: ------------------- -> http://permalink.gmane.org/gmane.linux.kernel/2082332
References: ----------- -> http://www.openwall.com/lists/oss-security/2015/11/10/1
ISSUE DESCRIPTION =================
Guests are currently permitted to modify all of the (writable) bits in the PCI command register of devices passed through to them. This in particular allows them to disable memory and I/O decoding on the device unless the device is an SR-IOV virtual function, in which case subsequent accesses to the respective MMIO or I/O port ranges would - - on PCI Express devices - lead to Unsupported Request responses. The treatmeant of such errors is platform specific.
IMPACT ======
In the event that the platform surfaces aforementioned UR responses as Non-Maskable Interrupts, and either the OS is configured to treat NMIs as fatal or (e.g. via ACPI's APEI) the platform tells the OS to treat these errors as fatal, the host would crash, leading to a Denial of Service.
VULNERABLE SYSTEMS ==================
Xen versions 3.3 and onwards are vulnerable due to supporting PCI pass-through. Upstream Linux versions 3.1 and onwards are vulnerable due to supporting PCI backend functionality. Other Linux versions as well as other OS versions may be vulnerable too.
Any domain which is given access to a non-SR-IOV virtual function PCI Express device can take advantage of this vulnerability.
MITIGATION ==========
This issue can be avoided by not assigning PCI Express devices other than SR-IOV virtual functions to untrusted guests.
RESOLUTION ==========
Applying the attached patch resolves this issue for upstream Linux.
xsa120.patch Linux 3.19
$ sha256sum xsa120.patch 5167215293d4a8a05f090fca5b20eb5878213a0158a0e7a12c245553db81a855 xsa120.patch
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
On 06/03/2025 4:48 am, Solar Designer wrote: Under Host UEFI Secure Boot, there is a security boundary between kernel code and root. Part of the requirement is "no unsigned code running privileged", and while this is technically a grey area (the malicious blob is signed; it's just not signed by AMD), it's also easy to argue that root definitely shouldn't be able to load a malicious microcode, just like it shouldn't be able to swap out the kernel with an unsigned one and reboot. Yes, but can't Xen's and the kernel's new protections be bypassed by MSR access via /dev/cpu//msr? The AMD microcode loader released by Google now doesn't appear to require more than that:
https://github.com/google/security-research/blob/master/pocs/cpus/entrysign/zentool/loader.c For Linux, /dev/cpu//msr isn't available when lockdown mode is active.
For Xen, guests can't load microcode at all (writes to the relevant MSRs are simply swallowed). Actually loading microcode is done via hypercall, restricted to privileged domains, and digest checking can't be disabled without a reboot (or a livepatch, which in a UEFI-SB model needs to itself be signed).
Answering Bastian's question from the other fork of this thread (sorry, I'm not CC'd).
Maintaining the hash list is a concern, but in the immediate term, the relevant maintainers in Linux and Xen.
Something better is being worked on, but there are challenges beyond just technical ones.
~Andrew
On Wed, Mar 05, 2025 at 07:11:23PM +0000, Andrew Cooper wrote: See:
https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html
Right now there are four known but (reasonably) benign microcodes from a non-AMD source. However, there is a tool to sign arbitrary microcode.
In Xen, we've provided a stopgap mitigation to perform extra checks on microcode load on affected CPU families. This is a SHA2 digest check against hashes with believed-good provenance. This is staging only for now, in case it is overly disruptive.
This will not protect against an already-compromised platform, but it will prevent an uncompromised system becoming compromised via Xen's microcode loading capabilities. Thank you, Andrew!
Maybe you can also clarify what Xen's threat model is here, and how this mitigation fits into it?
Specifically, what are "Xen's microcode loading capabilities" and are they in any way more exposed than the host system's root account? Even with Xen's mitigation above, host root can still load microcode without Xen involvement, right? Unless you block (at least) MSR access and kernel module loading?
Also, by "uncompromised system", do you specifically mean uncompromised at microcode level? If the threat is from a Xen administrator, then perhaps that's a partial security compromise already, just not yet extended to microcode.
These things may be obvious to someone more familiar with Xen, but your message and answers to the above are also interesting to the rest of us. On affected systems, the only complete fix is a firmware update. This is a very firmly recommended course of action.
Sincerely,
~Andrew, on behalf of the Xen Security Team. Alexander
Mishandling of guest SSBD selection on AMD hardware The current logic to set SSBD on AMD Family 17h and Hygon Family 18h processors requires that the setting of SSBD is coordinated at a core level, as the setting is shared between threads. Logic was introduced to keep track of how many threads require SSBD active in order to coordinate it, such logic relies on using a per-core counter of threads that have SSBD active. When running on the mentioned hardware, it's possible for a guest to under or overflow the thread counter, because each write to VIRTSPECCTRL.SSBD by the guest gets propagated to the helper that does the per-core active accounting. Underflowing the counter causes the value to get saturated, and thus attempts for guests running on the same core to set SSBD won't have effect because the hypervisor assumes it's already active.
x86 shadow plus log-dirty mode use-after-free In environments where host assisted address translation is necessary but Hardware Assisted Paging (HAP) is unavailable, Xen will run guests in so called shadow mode. Shadow mode maintains a pool of memory used for both shadow page tables as well as auxiliary data structures. To migrate or snapshot guests, Xen additionally runs them in so called log-dirty mode. The data structures needed by the log-dirty tracking are part of aformentioned auxiliary data. In order to keep error handling efforts within reasonable bounds, for operations which may require memory allocations shadow mode logic ensures up front that enough memory is available for the worst case requirements. Unfortunately, while page table memory is properly accounted for on the code path requiring the potential establishing of new shadows, demands by the log-dirty infrastructure were not taken into consideration. As a result, just established shadow page tables could be freed again immediately, while other code is still accessing them on the assumption that they would remain allocated.
An attacker with local access to a system (either through a disk or external drive) can present a modified XFS partition to grub-legacy in such a way to exploit a memory corruption in grub’s XFS file system implementation.
A division-by-zero error on some AMD processors can potentially return speculative data resulting in loss of confidentiality.
Last updated 25 April 2025
Last updated 25 April 2025
Last updated 11 April 2025
Last updated 25 April 2025
Last updated 25 April 2025
Last updated 25 April 2025
Last updated 25 April 2025
Last updated 25 April 2025
Last updated 11 April 2025