Xen vulnerabilities

When switching from Grant Table v2 to v1 in Xen, code holding the grant table lock but temporarily dropping and re-acquiring it wrongly assumes that table properties won't change during the window without the lock. This leads to issues with status frames that disappear when switching from v2 to v1.

When switching from Grant Table v1 to v2 in Xen, code holding the grant table lock but temporarily dropping and re-acquiring it wrongly assumes that table properties won't change during the window without the lock. This leads to a reduction in the number of valid grant references.

A guest with Populated on Demand (PoD) enabled may attempt to reclaim pages that are not regular guest RAM. This can cause corruption of memory management state in Xen.

The EVTCHNOP_expand_array hypercall checks for FIFO event channels being enabled, but without holding the correct lock. It can race with EVTCHNOP_reset, resulting in dereferencing a NULL pointer.

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.

Accesses to CMOS memory contents are done using an indirect IO port pair. 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, allowing a guest to change the index after it being checked, causing an out-of-bound read access.

Accessing vNUMA configuration data of a guest is still possible when domain destruction has already started. The cleanup of that configuration information is not synchronized with its retrieval by a device model controlling the guest.

When grant-copy operations are processed, permission checks may be carried out on a page different from the one involved in the copy when the grant is already pinned, leading to inconsistency.

Platform-op operations use a system-wide lock, but the lock acquisition lacks fairness, and with XSM/Flask enabled, the lock is acquired before permission checks. This is the platform-op issue.

Sysctl operations use a system-wide lock, but the lock acquisition lacks fairness, and with XSM/Flask enabled, the lock is acquired before permission checks. This is the sysctl issue.

Addressing certain issues related to long-running operations has proven overly costly. Since alternatives (HVM/PVH: HAP, PV: shim) are commonly available, the decision was to deprecate the functionality, while still retaining it for use at own risk. Memory-wise small guests may still be okay to run.

Xenstore uses a new XEN_DOMCTL_get_domain_state to track domains. The bitmap management is tied to the binding of VIRQ_DOM_EXC. Unfortunately, an error path can tear down the bitmap even when it wasn't set up. Unprivileged domains can trigger that error path.

An issue was discovered in Xen through 4.9.x allowing PV guest OS users to cause a denial of service (host OS crash) or gain host OS privileges in shadow mode by mapping a certain auxiliary page.

An issue was discovered in Xen through 4.9.x allowing guest OS users to cause a denial of service (host OS crash) or gain host OS privileges by leveraging incorrect error handling for reference counting in shadow mode.

An issue was discovered in Xen through 4.9.x allowing guest OS users to cause a denial of service (host OS crash) or gain host OS privileges. The issue arises from an incorrect mask for reference-count overflow checking in shadow mode.

An issue was discovered in Xen through 4.9.x allowing HVM guest OS users to gain privileges on the host OS, obtain sensitive information, or cause a denial of service (BUG and host OS crash) by leveraging the mishandling of Populate on Demand (PoD) Physical-to-Machine (P2M) errors.

A parameter verification issue was discovered in Xen through 4.9.x. The function `alloc_heap_pages` allows callers to specify the first NUMA node for allocations, but it does not properly handle the case where `node >= MAX_NUMNODES`, leading to out-of-bounds access to an internal array.

Xen allows local OS guest users to cause a denial of service (crash) or possibly obtain sensitive information or gain privileges via vectors involving transitive grants.

The grant-table feature in Xen through 4.8.x mishandles MMIO region grant references, allowing guest OS users to cause a denial of service (loss of grant trackability).

The grant-table feature in Xen through 4.8.x has a race condition leading to a double free, allowing guest OS users to cause a denial of service (memory consumption) or possibly obtain sensitive information or gain privileges.

Xen through 4.6.x on 64-bit platforms mishandles a failsafe callback, which might allow PV guest OS users to execute arbitrary code on the host OS.

The ioport_read and ioport_write functions in Xen may allow local x86 HVM guest OS administrators to gain qemu process privileges via out-of-range ioport access.

Xen through 4.8.x allows local 64-bit x86 HVM guest OS users to gain privileges by leveraging mishandling of SYSCALL singlestep during emulation.

Xen, when used on a system providing PV backends, allows local guest OS administrators to cause a denial of service (host OS crash) or gain privileges by writing to memory shared between the frontend and backend, known as a double fetch vulnerability.

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. This vulnerability exists because of an incomplete fix for CVE-2015-0777.

Xen 4.4.x running on ARM systems does not properly check write permissions on virtual addresses, allowing local guest administrators to gain privileges via unspecified vectors.

The vulnerability in Xen concerns the workaround for XSA-433 (Zenbleed), which was reworked but introduced an inverted conditional, causing the workaround to not be applied when needed and vice versa.

When oxenstored tears down a domain, node data is cleaned up but usage counts are leaked. When the domain ID is reused, the new domain can create fewer nodes before being deemed over quota.

In the viridian code (Xen), there is a race in the mapping of the reference TSC page where a guest can cause Xen to free a page while it is still present in the guest physical to machine (p2m) page tables. This is one of multiple issues related to guest memory handling in viridian, alongside CVE-2025-27466 and CVE-2025-58142.

In Xen viridian code, a NULL pointer dereference occurs by assuming the SIM page is mapped when a synthetic timer message must be delivered. This is one of three related issues in guest memory handling.

In Xen viridian code, a NULL pointer dereference occurs during the updating of the reference TSC area. This is one of three related issues in guest memory handling.

The grant-table feature in Xen through 4.8.x mishandles a GNTMAP_device_map and GNTMAP_host_map mapping, which can lead to count mismanagement and memory corruption. Guest OS users can cause a denial of service or gain privileged host OS access.

The shadow-paging feature in Xen through 4.8.x mismanages page references, leading to a race condition. This allows guest OS users to obtain Xen privileges, known as XSA-219.

The vulnerability in Xen concerns logic introduced for XSA-308, which does not handle a certain combination of VMX VMEntry state when #DB is intercepted, single stepping is active, and blocked by STI/MovSS. With branch tracing enabled, the prior adjustment still causes a VMEntry failure, fatal to the guest.

The vulnerability in Xen concerns issues with grant table operations, where v2 -> v1 -> v2 changes can lead to changes in the addresses of status pages. Previously calculated pointers into the status array may become stale, potentially leading to incorrect behavior.

The vulnerability in Xen concerns the XPTI (Xen Page Table Isolation) mechanism, which copies PV guest page table entries from guest-chosen root page tables to the Xen-chosen one. PV guests may have a directmap that does not cover all memory, especially when memory extends beyond the 5 TiB (or 3.5 TiB with CONFIG_BIGMEM=y) address boundary.

The vulnerability in Xenstore concerns live update, where the state record for a Xenstore watch with specified watch depth is written with two bytes missing. This results in an inconsistent state when reading the state back in the new Xenstore, causing a crash of Xenstore or wrong Xenstore data.

The vulnerability in Xen concerns the GNTTABOP_cache_flush operation, which may be issued on memory mapped from another domain using the grant table interface. There was no restriction to disallow the use of invalidate-without-clean against read-only grant mappings, which may corrupt the granted memory.

The vulnerability in Xen concerns the GNTTAB_cache_flush operation, where the error path after adding a NULL check fails to drop a page reference if the page is owned by a special system domain (DOM_IO or DOM_COW).

The vulnerability in Xen concerns the GNTTABOP_cache_flush operation, where the fix for XSA-437 introduced a calculation that may underflow, resulting in a loop that would take excessively long, potentially crashing the hypervisor, especially on 64-bit Arm.

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.

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

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.

Any guest can cause xenstored to crash by issuing an XS_RESET_WATCHES command within a transaction due to an assert() triggering. If xenstored was built with NDEBUG defined, nothing bad will happen, as assert() does nothing in that case. Note that the default is not to define NDEBUG for xenstored builds even in release builds of Xen.

A vulnerability in libxl (Xen) during PCI device detachment. The detach logic does not remove access permissions to 64-bit memory BARs, allowing a domain to retain access after the device is no longer assigned.

In Xen Viridian hypercalls, boundary checking bugs can cause out-of-bounds reads and writes when processing vCPU ID masks. For CVE-2025-58148, hypercalls using any input format can cause send_ipi() to read d->vcpu[] out-of-bounds and operate on a wild vCPU pointer.

In Xen Viridian hypercalls, boundary checking bugs can cause out-of-bounds reads and writes when processing vCPU ID masks. For CVE-2025-58147, hypercalls using the HV_VP_SET Sparse format can cause vpmask_set() to write out of bounds when converting the bitmap to Xen's format.

A vulnerability in the Xen hypervisor related to mapping pages belonging to other domains. The P2M lock is not held until a page reference is actually obtained (or the attempt fails), allowing the page to change type and even ownership, violating domain boundaries. This may lead to privilege escalation or breach of virtual machine isolation.

A vulnerability in the Xen hypervisor related to mapping pages belonging to other domains. An incorrect assertion in a case that actually needs handling could lead to a NULL pointer dereference on a release build.