grant-table: version change racing with other operations
[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
When grant-copy operations are processed, the respective grant may or may
not already be in use by another operation (a mapping or another copy).
For all copy operations the referenced guest frame is looked up. When
another operation is already active for the grant (the grant is "pinned"),
what is being supplied back to actually carry out permission checks and
copy operation may not be consistent: The permission check may be carried
out on a page different from the one involved in the copy.
[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.]
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
[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
[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
[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
[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
Addressing certain issues, in particular related to operations which may
take excessively long and therefore would need preemption, has turned out
overly costly. Since alternatives (HVM/PVH: HAP, PV: shim) are commonly
available, the decision was to deprecate the functionality, while still
retaining it for people to use at their own (security) risk. Memory-wise
small enough guests may still be okay to run.
oxenstored keeps quota related use counts across domain destruction
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.
Some shadow paging errors paths will switch the page-tables without
updating the currently running vCPU reference. This causes a mismatch
between the loaded page-tables and the mapcache metadata which can lead
to corruption of the mapcache.
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
To create and manage guests, domctl operations are used by the control
domain, a possible Xenstore domain, or by a domain controlling a
particular guest. Some of these operations may not be executed in
parallel, so a system-wide lock is used. The way that lock is acquired
is, however, not providing any fairness. This is CVE-2026-42489.
Furthermore, with XSM/Flask in use, the lock acquire will, for some
operations, occur ahead of any permission checking. This is
CVE-2026-42490.
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]
To create and manage guests, domctl operations are used by the control
domain, a possible Xenstore domain, or by a domain controlling a
particular guest. Some of these operations may not be executed in
parallel, so a system-wide lock is used. The way that lock is acquired
is, however, not providing any fairness. This is CVE-2026-42489.
Furthermore, with XSM/Flask in use, the lock acquire will, for some
operations, occur ahead of any permission checking. This is
CVE-2026-42490.
HVM guest I/O port accesses are subject to either emulation or at least
translation. Translations are managed by the device model (via
XEN_DOMCTL_ioport_mapping), and hence the linked list used may changed
at any time. Traversal of those lists (while handling guest I/O port
accesses) therefore needs synchronizing with updates, which was missing
so far.
The adjustments made for XSA-379 as well as those subsequently becoming
XSA-387 still left a race window, when a HVM or PVH guest does a grant
table version change from v2 to v1 in parallel with mapping the status
page(s) via XENMEM_add_to_physmap. Some of the status pages may then be
freed while mappings of them would still be inserted into the guest's
secondary (P2M) page tables.
Any guest can cause xenstored to crash by issuing a XS_RESET_WATCHES
command within a transaction due to an assert() triggering.
In case xenstored was built with NDEBUG #defined nothing bad will
happen, as assert() is doing nothing in this case. Note that the
default is not to define NDEBUG for xenstored builds even in release
builds of Xen.
Improper isolation of shared resources within the CPU operation cache on Zen 2-based products could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation.
A transient execution vulnerability within AMD CPUs may allow a local user-privileged attacker to leak data via the floating point divisor unit, potentially resulting in loss of confidentiality.