| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| [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 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. |
| When setting up interrupt remapping for legacy PCI(-X) devices,
including PCI(-X) bridges, a lookup of the upstream bridge is required.
This lookup, itself involving acquiring of a lock, is done in a context
where acquiring that lock is unsafe. This can lead to a deadlock. |
| In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: fix crash when removing device
When removing a netfront device directly after a suspend/resume cycle
it might happen that the queues have not been setup again, causing a
crash during the attempt to stop the queues another time.
Fix that by checking the queues are existing before trying to stop
them.
This is XSA-465 / CVE-2024-53240. |
| 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. |
| PVH guests have their ACPI tables constructed by the toolstack. The
construction involves building the tables in local memory, which are
then copied into guest memory. While actually used parts of the local
memory are filled in correctly, excess space that is being allocated is
left with its prior contents. |
| A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths. |
| 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
|
| 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.
|
| In x86's APIC (Advanced Programmable Interrupt Controller) architecture,
error conditions are reported in a status register. Furthermore, the OS
can opt to receive an interrupt when a new error occurs.
It is possible to configure the error interrupt with an illegal vector,
which generates an error when an error interrupt is raised.
This case causes Xen to recurse through vlapic_error(). The recursion
itself is bounded; errors accumulate in the the status register and only
generate an interrupt when a new status bit becomes set.
However, the lock protecting this state in Xen will try to be taken
recursively, and deadlock. |
| 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.
|
| When a transaction is committed, C Xenstored will first check
the quota is correct before attempting to commit any nodes. It would
be possible that accounting is temporarily negative if a node has
been removed outside of the transaction.
Unfortunately, some versions of C Xenstored are assuming that the
quota cannot be negative and are using assert() to confirm it. This
will lead to C Xenstored crash when tools are built without -DNDEBUG
(this is the default).
|
| The fix for XSA-423 added logic to Linux'es netback driver to deal with
a frontend splitting a packet in a way such that not all of the headers
would come in one piece. Unfortunately the logic introduced there
didn't account for the extreme case of the entire packet being split
into as many pieces as permitted by the protocol, yet still being
smaller than the area that's specially dealt with to keep all (possible)
headers together. Such an unusual packet would therefore trigger a
buffer overrun in the driver. |
| 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.
|
| Arm provides multiple helpers to clean & invalidate the cache
for a given region. This is, for instance, used when allocating
guest memory to ensure any writes (such as the ones during scrubbing)
have reached memory before handing over the page to a guest.
Unfortunately, the arithmetics in the helpers can overflow and would
then result to skip the cache cleaning/invalidation. Therefore there
is no guarantee when all the writes will reach the memory.
This undefined behavior was meant to be addressed by XSA-437, but the
approach was not sufficient. |
| For migration as well as to work around kernels unaware of L1TF (see
XSA-273), PV guests may be run in shadow paging mode. Since Xen itself
needs to be mapped when PV guests run, Xen and shadowed PV guests run
directly the respective shadow page tables. For 64-bit PV guests this
means running on the shadow of the guest root page table.
In the course of dealing with shortage of memory in the shadow pool
associated with a domain, shadows of page tables may be torn down. This
tearing down may include the shadow root page table that the CPU in
question is presently running on. While a precaution exists to
supposedly prevent the tearing down of the underlying live page table,
the time window covered by that precaution isn't large enough.
|
