[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.
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.
An issue was discovered in the Linux kernel through 5.10.1, as used with Xen through 4.14.x. The Linux kernel PV block backend expects the kernel thread handler to reset ring->xenblkd to NULL when stopped. However, the handler may not have time to run if the frontend quickly toggles between the states connect and disconnect. As a consequence, the block backend may re-use a pointer after it was freed. A misbehaving guest can trigger a dom0 crash by continuously connecting / disconnecting a block frontend. Privilege escalation and information leaks cannot be ruled out. This only affects systems with a Linux blkback.
An issue was discovered in Xen through 4.14.x. Some OSes (such as Linux, FreeBSD, and NetBSD) are processing watch events using a single thread. If the events are received faster than the thread is able to handle, they will get queued. As the queue is unbounded, a guest may be able to trigger an OOM in the backend. All systems with a FreeBSD, Linux, or NetBSD (any version) dom0 are vulnerable.
An issue was discovered in Xen through 4.14.x. There is a race condition when migrating timers between x86 HVM vCPUs. When migrating timers of x86 HVM guests between its vCPUs, the locking model used allows for a second vCPU of the same guest (also operating on the timers) to release a lock that it didn't acquire. The most likely effect of the issue is a hang or crash of the hypervisor, i.e., a Denial of Service (DoS). All versions of Xen are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only x86 HVM guests can leverage the vulnerability. x86 PV and PVH cannot leverage the vulnerability. Only guests with more than one vCPU can exploit the vulnerability.
An issue was discovered in Xen through 4.14.x. There are evtchnreset() race conditions. Uses of EVTCHNOPreset (potentially by a guest on itself) or XENDOMCTLsoftreset (by itself covered by XSA-77) can lead to the violation of various internal assumptions. This may lead to out of bounds memory accesses or triggering of bug checks. In particular, x86 PV guests may be able to elevate their privilege to that of the host. Host and guest crashes are also possible, leading to a Denial of Service (DoS). Information leaks cannot be ruled out. All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier are not vulnerable.
An issue was discovered in Xen through 4.14.x. Out of bounds event channels are available to 32-bit x86 domains. The so called 2-level event channel model imposes different limits on the number of usable event channels for 32-bit x86 domains vs 64-bit or Arm (either bitness) ones. 32-bit x86 domains can use only 1023 channels, due to limited space in their shared (between guest and Xen) information structure, whereas all other domains can use up to 4095 in this model. The recording of the respective limit during domain initialization, however, has occurred at a time where domains are still deemed to be 64-bit ones, prior to actually honoring respective domain properties. At the point domains get recognized as 32-bit ones, the limit didn't get updated accordingly. Due to this misbehavior in Xen, 32-bit domains (including Domain 0) servicing other domains may observe event channel allocations to succeed when they should really fail. Subsequent use of such event channels would then possibly lead to corruption of other parts of the shared info structure. An unprivileged guest may cause another domain, in particular Domain 0, to misbehave. This may lead to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only x86 32-bit domains servicing other domains are vulnerable. Arm systems, as well as x86 64-bit domains, are not vulnerable.
An issue was discovered in Xen through 4.14.x. An x86 PV guest can trigger a host OS crash when handling guest access to MSRMISCENABLE. When a guest accesses certain Model Specific Registers, Xen first reads the value from hardware to use as the basis for auditing the guest access. For the MISCENABLE MSR, which is an Intel specific MSR, this MSR read is performed without error handling for a #GP fault, which is the consequence of trying to read this MSR on non-Intel hardware. A buggy or malicious PV guest administrator can crash Xen, resulting in a host Denial of Service. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only Xen versions 4.11 and onwards are vulnerable. 4.10 and earlier are not vulnerable. Only x86 systems that do not implement the MISCENABLE MSR (0x1a0) are vulnerable. AMD and Hygon systems do not implement this MSR and are vulnerable. Intel systems do implement this MSR and are not vulnerable. Other manufacturers have not been checked. Only x86 PV guests can exploit the vulnerability. x86 HVM/PVH guests cannot exploit the vulnerability.
An issue was discovered in Xen through 4.14.x. There is a lack of preemption in evtchnreset() / evtchndestroy(). In particular, the FIFO event channel model allows guests to have a large number of event channels active at a time. Closing all of these (when resetting all event channels or when cleaning up after the guest) may take extended periods of time. So far, there was no arrangement for preemption at suitable intervals, allowing a CPU to spend an almost unbounded amount of time in the processing of these operations. Malicious or buggy guest kernels can mount a Denial of Service (DoS) attack affecting the entire system. All Xen versions are vulnerable in principle. Whether versions 4.3 and older are vulnerable depends on underlying hardware characteristics.
An issue was discovered in Xen through 4.14.x. There are missing memory barriers when accessing/allocating an event channel. Event channels control structures can be accessed lockless as long as the port is considered to be valid. Such a sequence is missing an appropriate memory barrier (e.g., smpmb()) to prevent both the compiler and CPU from re-ordering access. A malicious guest may be able to cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded. Systems running all versions of Xen are affected. Whether a system is vulnerable will depend on the CPU and compiler used to build Xen. For all systems, the presence and the scope of the vulnerability depend on the precise re-ordering performed by the compiler used to build Xen. We have not been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code (with which code generation options). GCC documentation clearly suggests that re-ordering is possible. Arm systems will also be vulnerable if the CPU is able to re-order memory access. Please consult your CPU vendor. x86 systems are only vulnerable if a compiler performs re-ordering.
An issue was discovered in Xen through 4.14.x. x86 PV guest kernels can experience denial of service via SYSENTER. The SYSENTER instruction leaves various state sanitization activities to software. One of Xen's sanitization paths injects a #GP fault, and incorrectly delivers it twice to the guest. This causes the guest kernel to observe a kernel-privilege #GP fault (typically fatal) rather than a user-privilege #GP fault (usually converted into SIGSEGV/etc.). Malicious or buggy userspace can crash the guest kernel, resulting in a VM Denial of Service. All versions of Xen from 3.2 onwards are vulnerable. Only x86 systems are vulnerable. ARM platforms are not vulnerable. Only x86 systems that support the SYSENTER instruction in 64bit mode are vulnerable. This is believed to be Intel, Centaur, and Shanghai CPUs. AMD and Hygon CPUs are not believed to be vulnerable. Only x86 PV guests can exploit the vulnerability. x86 PVH / HVM guests cannot exploit the vulnerability.
An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that an event channel, once valid, will not become invalid over the life time of a guest. However, operations like the resetting of all event channels may involve decreasing one of the bounds checked when determining validity. This may lead to bug checks triggering, crashing the host. An unprivileged guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only systems with untrusted guests permitted to create more than the default number of event channels are vulnerable. This number depends on the architecture and type of guest. For 32-bit x86 PV guests, this is 1023; for 64-bit x86 PV guests, and for all ARM guests, this number is 4095. Systems where untrusted guests are limited to fewer than this number are not vulnerable. Note that xl and libxl limit maxeventchannels to 1023 by default, so systems using exclusively xl, libvirt+libxl, or their own toolstack based on libxl, and not explicitly setting maxeventchannels, are not vulnerable.
An issue was discovered in Xen through 4.14.x. The PCI passthrough code improperly uses register data. Code paths in Xen's MSI handling have been identified that act on unsanitized values read back from device hardware registers. While devices strictly compliant with PCI specifications shouldn't be able to affect these registers, experience shows that it's very common for devices to have out-of-spec "backdoor" operations that can affect the result of these reads. A not fully trusted guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. Privilege escalation and information leaks cannot be excluded. All versions of Xen supporting PCI passthrough are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only guests with passed through PCI devices may be able to leverage the vulnerability. Only systems passing through devices with out-of-spec ("backdoor") functionality can cause issues. Experience shows that such out-of-spec functionality is common; unless you have reason to believe that your device does not have such functionality, it's better to assume that it does.
An issue was discovered in Xen through 4.13.x, allowing Intel guest OS users to gain privileges or cause a denial of service because of non-atomic modification of a live EPT PTE. When mapping guest EPT (nested paging) tables, Xen would in some circumstances use a series of non-atomic bitfield writes. Depending on the compiler version and optimisation flags, Xen might expose a dangerous partially written PTE to the hardware, which an attacker might be able to race to exploit. A guest administrator or perhaps even an unprivileged guest user might be able to cause denial of service, data corruption, or privilege escalation. Only systems using Intel CPUs are vulnerable. Systems using AMD CPUs, and Arm systems, are not vulnerable. Only systems using nested paging (hap, aka nested paging, aka in this case Intel EPT) are vulnerable. Only HVM and PVH guests can exploit the vulnerability. The presence and scope of the vulnerability depends on the precise optimisations performed by the compiler used to build Xen. If the compiler generates (a) a single 64-bit write, or (b) a series of read-modify-write operations in the same order as the source code, the hypervisor is not vulnerable. For example, in one test build using GCC 8.3 with normal settings, the compiler generated multiple (unlocked) read-modify-write operations in source-code order, which did not constitute a vulnerability. We have not been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code (with which code-generation options). The source code clearly violates the C rules, and thus should be considered vulnerable.