| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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.
|
| 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
|
| 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. |
| 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. |
| 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 HV_VP_SET Sparse format can
cause vpmask_set() to write out of bounds when converting the bitmap
to Xen's format.
* 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. |
| [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 HV_VP_SET Sparse format can
cause vpmask_set() to write out of bounds when converting the bitmap
to Xen's format.
* 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. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
There are two issues related to the mapping of pages belonging to other
domains: For one, an assertion is wrong there, where the case actually
needs handling. A NULL pointer de-reference could result on a release
build. This is CVE-2025-58144.
And then the P2M lock isn't held until a page reference was actually
obtained (or the attempt to do so has failed). Otherwise the page can
not only change type, but even ownership in between, thus allowing
domain boundaries to be violated. This is CVE-2025-58145. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
There are two issues related to the mapping of pages belonging to other
domains: For one, an assertion is wrong there, where the case actually
needs handling. A NULL pointer de-reference could result on a release
build. This is CVE-2025-58144.
And then the P2M lock isn't held until a page reference was actually
obtained (or the attempt to do so has failed). Otherwise the page can
not only change type, but even ownership in between, thus allowing
domain boundaries to be violated. This is CVE-2025-58145. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
There are multiple issues related to the handling and accessing of guest
memory pages in the viridian code:
1. A NULL pointer dereference in the updating of the reference TSC area.
This is CVE-2025-27466.
2. A NULL pointer dereference by assuming the SIM page is mapped when
a synthetic timer message has to be delivered. This is
CVE-2025-58142.
3. A race in the mapping of the reference TSC page, where a guest can
get Xen to free a page while still present in the guest physical to
machine (p2m) page tables. This is CVE-2025-58143. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
There are multiple issues related to the handling and accessing of guest
memory pages in the viridian code:
1. A NULL pointer dereference in the updating of the reference TSC area.
This is CVE-2025-27466.
2. A NULL pointer dereference by assuming the SIM page is mapped when
a synthetic timer message has to be delivered. This is
CVE-2025-58142.
3. A race in the mapping of the reference TSC page, where a guest can
get Xen to free a page while still present in the guest physical to
machine (p2m) page tables. This is CVE-2025-58143. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
There are multiple issues related to the handling and accessing of guest
memory pages in the viridian code:
1. A NULL pointer dereference in the updating of the reference TSC area.
This is CVE-2025-27466.
2. A NULL pointer dereference by assuming the SIM page is mapped when
a synthetic timer message has to be delivered. This is
CVE-2025-58142.
3. A race in the mapping of the reference TSC page, where a guest can
get Xen to free a page while still present in the guest physical to
machine (p2m) page tables. This is CVE-2025-58143. |
| 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. |
| The fixes for XSA-422 (Branch Type Confusion) and XSA-434 (Speculative
Return Stack Overflow) are not IRQ-safe. It was believed that the
mitigations always operated in contexts with IRQs disabled.
However, the original XSA-254 fix for Meltdown (XPTI) deliberately left
interrupts enabled on two entry paths; one unconditionally, and one
conditionally on whether XPTI was active.
As BTC/SRSO and Meltdown affect different CPU vendors, the mitigations
are not active together by default. Therefore, there is a race
condition whereby a malicious PV guest can bypass BTC/SRSO protections
and launch a BTC/SRSO attack against Xen.
|
| The current setup of the quarantine page tables assumes that the
quarantine domain (dom_io) has been initialized with an address width
of DEFAULT_DOMAIN_ADDRESS_WIDTH (48) and hence 4 page table levels.
However dom_io being a PV domain gets the AMD-Vi IOMMU page tables
levels based on the maximum (hot pluggable) RAM address, and hence on
systems with no RAM above the 512GB mark only 3 page-table levels are
configured in the IOMMU.
On systems without RAM above the 512GB boundary
amd_iommu_quarantine_init() will setup page tables for the scratch
page with 4 levels, while the IOMMU will be configured to use 3 levels
only, resulting in the last page table directory (PDE) effectively
becoming a page table entry (PTE), and hence a device in quarantine
mode gaining write access to the page destined to be a PDE.
Due to this page table level mismatch, the sink page the device gets
read/write access to is no longer cleared between device assignment,
possibly leading to data leaks.
|
|
[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.
|
|
[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.
|
| The caching invalidation guidelines from the AMD-Vi specification (48882—Rev
3.07-PUB—Oct 2022) is incorrect on some hardware, as devices will malfunction
(see stale DMA mappings) if some fields of the DTE are updated but the IOMMU
TLB is not flushed.
Such stale DMA mappings can point to memory ranges not owned by the guest, thus
allowing access to unindented memory regions.
|
|
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
libfsimage contains parsing code for several filesystems, most of them based on
grub-legacy code. libfsimage is used by pygrub to inspect guest disks.
Pygrub runs as the same user as the toolstack (root in a priviledged domain).
At least one issue has been reported to the Xen Security Team that allows an
attacker to trigger a stack buffer overflow in libfsimage. After further
analisys the Xen Security Team is no longer confident in the suitability of
libfsimage when run against guest controlled input with super user priviledges.
In order to not affect current deployments that rely on pygrub patches are
provided in the resolution section of the advisory that allow running pygrub in
deprivileged mode.
CVE-2023-4949 refers to the original issue in the upstream grub
project ("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.") CVE-2023-34325 refers specifically to
the vulnerabilities in Xen's copy of libfsimage, which is decended
from a very old version of grub.
|
