In the context switch logic Xen attempts to skip an IBPB in the case of
a vCPU returning to a CPU on which it was the previous vCPU to run.
While safe for Xen's isolation between vCPUs, this prevents the guest
kernel correctly isolating between tasks. Consider:
1) vCPU runs on CPU A, running task 1.
2) vCPU moves to CPU B, idle gets scheduled on A. Xen skips IBPB.
3) On CPU B, guest kernel switches from task 1 to 2, issuing IBPB.
4) vCPU moves back to CPU A. Xen skips IBPB again.
Now, task 2 is running on CPU A with task 1's training still in the BTB.
Shadow mode tracing code uses a set of per-CPU variables to avoid
cumbersome parameter passing. Some of these variables are written to
with guest controlled data, of guest controllable size. That size can
be larger than the variable, and bounding of the writes was missing.
[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.
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.]
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.