oxenstored keeps quota related use counts across domain destruction

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.

XAPI UTF-8 string handling

There are multiple issues. 1. Updates to the XAPI database sanitise input strings, but try generating the notification using the unsanitised input. This causes the database's event thread to terminate and cease further processing. 2. XAPI's UTF-8 encoder implements v3.0 of the Unicode spec, but XAPI uses libraries which conform to the stricter v3.1 of the Unicode spec. This causes some strings to be accepted as valid UTF-8 by XAPI, but rejected by other libraries in use. Notably, such strings can be entered into the database, after which the database can no longer be loaded. 3. There is no input sanitisation for Map/Set updates on objects in the XAPI database.

Multiple RBAC issues in XAPI

[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.other_config: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:is_system_domain 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.other_config:storage_driver_domain 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:hvm_serial parameter, which should be restricted to the pool-admin role, as it can allow arbitrary dom0 file write.

Multiple RBAC issues in XAPI

[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.other_config: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:is_system_domain 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.other_config:storage_driver_domain 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:hvm_serial parameter, which should be restricted to the pool-admin role, as it can allow arbitrary dom0 file write.

Multiple RBAC issues in XAPI

[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.other_config: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:is_system_domain 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.other_config:storage_driver_domain 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:hvm_serial parameter, which should be restricted to the pool-admin role, as it can allow arbitrary dom0 file write.

Multiple RBAC issues in XAPI

[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.other_config: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:is_system_domain 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.other_config:storage_driver_domain 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:hvm_serial parameter, which should be restricted to the pool-admin role, as it can allow arbitrary dom0 file write.

Multiple RBAC issues in XAPI

[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.other_config: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:is_system_domain 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.other_config:storage_driver_domain 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:hvm_serial parameter, which should be restricted to the pool-admin role, as it can allow arbitrary dom0 file write.

domctl lock open to abuse

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] To create and manage guests, domctl operations are used by the control domain, a possible Xenstore domain, or by a domain controlling a particular guest. Some of these operations may not be executed in parallel, so a system-wide lock is used. The way that lock is acquired is, however, not providing any fairness. This is CVE-2026-42489. Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking. This is CVE-2026-42490.

domctl lock open to abuse

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] To create and manage guests, domctl operations are used by the control domain, a possible Xenstore domain, or by a domain controlling a particular guest. Some of these operations may not be executed in parallel, so a system-wide lock is used. The way that lock is acquired is, however, not providing any fairness. This is CVE-2026-42489. Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking. This is CVE-2026-42490.

x86: mismatched mapcache metadata

Some shadow paging errors paths will switch the page-tables without updating the currently running vCPU reference. This causes a mismatch between the loaded page-tables and the mapcache metadata which can lead to corruption of the mapcache.

x86 HVM I/O port list traversal

HVM guest I/O port accesses are subject to either emulation or at least translation. Translations are managed by the device model (via XEN_DOMCTL_ioport_mapping), and hence the linked list used may changed at any time. Traversal of those lists (while handling guest I/O port accesses) therefore needs synchronizing with updates, which was missing so far.

x86/AMD: Debug Mask handling

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] AMD CPUs since ~2014 have extensions to normal x86 debugging functionality. Xen supports guests using these extensions. Unfortunately there are errors in Xen's handling of the guest state, leading to denials of service. 1) CVE-2023-34327 - An HVM vCPU can end up operating in the context of a previous vCPUs debug mask state. 2) CVE-2023-34328 - A PV vCPU can place a breakpoint over the live GDT. This allows the PV vCPU to exploit XSA-156 / CVE-2015-8104 and lock up the CPU entirely.

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

xen: non-maskable interrupts triggerable by guests (xsa120)

Xen allows guest OS users to obtain sensitive information from uninitialized locations in host OS kernel memory by not enabling memory and I/O decoding control bits. NOTE: this vulnerability exists because of an incomplete fix for CVE-2015-0777.

Xenstored DoS via XS_RESET_WATCHES command

Any guest can cause xenstored to crash by issuing a XS_RESET_WATCHES 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.

grant table v2 race in status page mapping

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

xen: insecure temporary file use in qemu-dm.debug

qemu-dm.debug in Xen 3.2.1 allows local users to overwrite arbitrary files via a symlink attack on the /tmp/args temporary file.

xen QEMU NE2000 emulation issues

Integer signedness error in the NE2000 emulator in QEMU 0.8.2, as used in Xen and possibly other products, allows local users to trigger a heap-based buffer overflow via certain register values that bypass sanity checks, aka QEMU NE2000 "receive" integer signedness error. NOTE: this identifier was inadvertently used by some sources to cover multiple issues that were labeled "NE2000 network driver and the socket code," but separate identifiers have been created for the individual vulnerabilities since there are sometimes different fixes; see CVE-2007-5729 and CVE-2007-5730.

Heap-based buffer overflow in the flask_security_label function in Xen 3.3, when compiled with the XSM:FLASK module, allows unprivileged domain users (domU) to execute arbitrary code via the flask_op hypercall.

xen/qemu Cirrus LGD-54XX "bitblt" Heap Overflow

Multiple heap-based buffer overflows in the cirrus_invalidate_region function in the Cirrus VGA extension in QEMU 0.8.2, as used in Xen and possibly other products, might allow local users to execute arbitrary code via unspecified vectors related to "attempting to mark non-existent regions as dirty," aka the "bitblt" heap overflow.