| 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.]
To manage the system, sysctl and platform operations are used by the
control domain or a possible Xenstore domain. Some of these operations
may not be executed in parallel, so a system-wide lock each is used.
The way those locks are acquired is, however, not providing any fairness.
Furthermore, with XSM/Flask in use, the lock acquire will, for some
operations, occur ahead of any permission checking.
The sysctl issue is CVE-2026-62426.
The platform-op issue is CVE-2026-62427. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
To manage the system, sysctl and platform operations are used by the
control domain or a possible Xenstore domain. Some of these operations
may not be executed in parallel, so a system-wide lock each is used.
The way those locks are acquired is, however, not providing any fairness.
Furthermore, with XSM/Flask in use, the lock acquire will, for some
operations, occur ahead of any permission checking.
The sysctl issue is CVE-2026-62426.
The platform-op issue is CVE-2026-62427. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
With the introduction of Grant Table v2 came the requirement to be able to
switch between versions. Switching from v1 to v2 reduces the number of
valid grant references, as a bigger shared entry structure is then needed
while the shared table doesn't change size. Switching from v2 back to v1
the status frames, which are separate in v2, go away.
Code holding, but intermediately dropping and then re-acquiring the grant
table lock, sometimes wrongly assumes that said properties wouldn't change
across the window in time where the lock is not being held.
The v1 -> v2 issue is CVE-2026-62435.
The v2 -> v1 issue is CVE-2026-62436. |
| The EVTCHNOP_expand_array hypercall checks for whether FIFO event
channels are enabled, but without holding the correct lock. It can race
with EVTCHNOP_reset, resulting in dereferencing a NULL pointer. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver
derives several lengths directly from attacker-controlled on-disk fields
without validating them:
* The directory loop itself assumes a good record length. This is
CVE-2026-42494.
* The calculation of the System Use area may underflow. This is
CVE-2026-42495.
* The Rock Ridge extension loop assumes a good (inner) record length.
This is CVE-2026-62423.
* The Rock Ridge NM record processing assumes a good entry length.
This is CVE-2026-62424.
* The Rock Ridge CE record processing assumes a good size and offset.
This is CVE-2026-62425. |
| A guest started with Populated on Demand enabled (PoD) can attempt to
reclaim pages which aren't regular guest RAM. This can cause corruption
of memory management state in Xen. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
With the introduction of Grant Table v2 came the requirement to be able to
switch between versions. Switching from v1 to v2 reduces the number of
valid grant references, as a bigger shared entry structure is then needed
while the shared table doesn't change size. Switching from v2 back to v1
the status frames, which are separate in v2, go away.
Code holding, but intermediately dropping and then re-acquiring the grant
table lock, sometimes wrongly assumes that said properties wouldn't change
across the window in time where the lock is not being held.
The v1 -> v2 issue is CVE-2026-62435.
The v2 -> v1 issue is CVE-2026-62436. |
| Accessing the vNUMA configuration data of a guest is still possible when
domain destruction has already started. The cleaning up of that
configuration information is not synchronized with its retrieval by a
device model controlling the guest. |
| Accesses to the CMOS memory contents are done using an indirect IO port
pair. Therefore 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. As a result, a guest could change the index after
it being checked, causing a subsequent out-of-bound read access to the
contents of an array. |
| 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. |
| Parts of the DM_OP handling code assumes the caller has provided the
required number of buffers for the given operation without any checking
being done. As a result, certain operations might access stack
rubble as structures are possibly uninitialized. |
| Xenstore, to have an up-to-date picture of the entire system, wants to
know of domains appearing and disappearing. To make this more robust, a
new XEN_DOMCTL_get_domain_state was introduced. The management of the
bitmap underlying that operation is tied into the binding of the
VIRQ_DOM_EXC virtual IRQ. Unfortunately an error path there would tear
down the bitmap even in cases when it wasn't set up. Unprivileged domains
can trigger that error path. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver
derives several lengths directly from attacker-controlled on-disk fields
without validating them:
* The directory loop itself assumes a good record length. This is
CVE-2026-42494.
* The calculation of the System Use area may underflow. This is
CVE-2026-42495.
* The Rock Ridge extension loop assumes a good (inner) record length.
This is CVE-2026-62423.
* The Rock Ridge NM record processing assumes a good entry length.
This is CVE-2026-62424.
* The Rock Ridge CE record processing assumes a good size and offset.
This is CVE-2026-62425. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver
derives several lengths directly from attacker-controlled on-disk fields
without validating them:
* The directory loop itself assumes a good record length. This is
CVE-2026-42494.
* The calculation of the System Use area may underflow. This is
CVE-2026-42495.
* The Rock Ridge extension loop assumes a good (inner) record length.
This is CVE-2026-62423.
* The Rock Ridge NM record processing assumes a good entry length.
This is CVE-2026-62424.
* The Rock Ridge CE record processing assumes a good size and offset.
This is CVE-2026-62425. |
| [This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver
derives several lengths directly from attacker-controlled on-disk fields
without validating them:
* The directory loop itself assumes a good record length. This is
CVE-2026-42494.
* The calculation of the System Use area may underflow. This is
CVE-2026-42495.
* The Rock Ridge extension loop assumes a good (inner) record length.
This is CVE-2026-62423.
* The Rock Ridge NM record processing assumes a good entry length.
This is CVE-2026-62424.
* The Rock Ridge CE record processing assumes a good size and offset.
This is CVE-2026-62425. |
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]
The Windows PV drivers expose various facilities to userspace. Several
of these have no security descriptor, and are therefore fully accessible
to unprivileged users. These are:
1. XenCons, CVE-2025-27462
2. XenIface, CVE-2025-27463
3. XenBus, CVE-2025-27464 |
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] The Windows PV drivers expose various facilities to userspace. Several of these have no security descriptor, and are therefore fully accessible to unprivileged users. These are: 1. XenCons, CVE-2025-27462 2. XenIface, CVE-2025-27463 3. XenBus, CVE-2025-27464 |
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] The Windows PV drivers expose various facilities to userspace. Several of these have no security descriptor, and are therefore fully accessible to unprivileged users. These are: 1. XenCons, CVE-2025-27462 2. XenIface, CVE-2025-27463 3. XenBus, CVE-2025-27464 |
| varstored is a component of the Xapi toolstack handling UEFI Variables
for a VM. It has a communication path with OVMF inside the VM involving
mapping a buffer prepared by OVMF.
Within varstored, there were insufficient compiler barriers, creating
TOCTOU issues with data in the shared buffer.
The exact vulnerable behaviour depends on the code generated by the
compiler. In a build of varstored using default settings, the attacker
can control an index used in a jump table. |
| 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. |
