Andrew Cooper

[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.

Name of the Vulnerable Software and Affected Versions: xen (affected versions not specified) Description: The issue allows an unprivileged guest to cause a hypervisor crash, resulting in a Denial of Service (DoS) of the entire host. This is due to incorrect stubs exception handling for flags recovery. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

The issue is related to the x86/xen component of the Linux kernel, where the PV iret hypercall was previously done through the hypercall page. This has been changed to directly code the required sequence in xen-asm.S, in preparation for no longer using the hypercall page due to problems with speculation mitigations. The vulnerability may allow a remote attacker to gain unauthorized access to protected information due to an incorrect sequence of processor instructions resulting from the lack of an ENDBR instruction and prolog/epilog for hash-based CFI schemes.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: The issue is related to a "Meltdown Lite" problem with non-canonical accesses in kernel space, which can lead to the leakage of speculative data. This is due to the use of just the high bit to decide whether an access is in user space or kernel space. The kernel has been updated to surround the access with a STAC/CLAC pair, which serializes execution on older Zen architectures and closes the speculation window. However, this is not effective on Zen 5 architectures, which rename the AC bit and improve the performance of STAC/CLAC, but also open the speculation window. The issue affects the new address masking, as well as the regular valid user address() check used by access ok(), and the asm version of the sign bit check in the get user() helpers. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

The issue is related to a logical error in the mitigation for Branch Type Confusion, which is not applied properly when intended. This error also impacts Speculative Return Stack Overflow, as it uses the same infrastructure. The vulnerability may allow an attacker to access confidential information and elevate their privileges.

A race condition in System Management Mode (SMM) code may allow an attacker using a compromised user space to potentially result in privilege escalation.

The issue is related to insufficient protections in System Management Mode (SMM) code, which may allow an attacker to potentially enable escalation of privilege via local access.

The issue is related to the fixes for Branch Type Confusion and Speculative Return Stack Overflow not being IRQ-safe. It was believed that the mitigations always operated in contexts with IRQs disabled. However, the original fix for Meltdown deliberately left interrupts enabled on two entry paths. As a result, there is a race condition whereby a malicious PV guest can bypass protections and launch an attack against Xen. This can allow an attacker to infer the contents of memory belonging to other guests. Xen is only vulnerable in default configurations on AMD and Hygon CPUs.

Insufficient protections in System Management Mode (SMM) code may allow an attacker to potentially enable escalation of privilege via local access.

The issue is related to a security problem, but specific details are not provided.

The issue affects AMD CPUs with extensions to normal x86 debugging functions, introduced in CPUs since around 2014.

The issue is related to a security problem, but specific details are not provided.

The issue is related to a security problem, but specific details are not provided. No information is available about the estimated number of potentially affected devices or real-world incidents.

The issue is related to a speculative vulnerability in the 32bit SYSCALL path. Due to an oversight in the original Spectre/Meltdown security work, one entry path performs its speculation-safety actions too late. In some configurations, there is an unprotected RET instruction which can be attacked with a variety of speculative attacks.

The issue concerns unintended memory sharing between guests on Intel systems that support the "virtualize APIC accesses" feature. A guest can read and write the global shared xAPIC page by moving the local APIC out of xAPIC mode, bypassing the expected isolation between two guests.

The issue is related to long running loops in grant table handling. Xen maintains information on grant mappings a domain may create to map grants offered by other domains. When carrying out certain actions, Xen iterates over all such entries, including ones that aren't in use anymore and some that may have been created but never used. If the number of entries for a given domain is large enough, this iteration may tie up a CPU for too long, starving other domains or causing issues in the hypervisor itself. A domain may map its own grants, and a pair of "cooperating" guests may cause the effects to be more severe.

This issue relates to the TSX Async Abort speculative security vulnerability, which can lead to information disclosure. An attacker, acting remotely, may be able to access confidential data. The vulnerability is associated with the x86 architecture and the TSX Async Abort protections not being restored after S3 suspend. Mitigating this issue by disabling TSX requires selecting a non-default setting in `MSR TSX CTRL`, but this setting is not restored after S3 suspend.

The issue is related to inappropriate x86 IOMMU timeout detection and handling. IOMMUs process commands in parallel with the operation of the CPU(s) issuing such commands. In the current implementation in Xen, asynchronous notification of the completion of such commands is not used, and the issuing CPU spin-waits for the completion of the most recently issued command(s). Some of these waiting loops try to apply a timeout to fail overly-slow commands. However, the course of action upon a perceived timeout actually being detected is inappropriate, potentially causing guests to be marked as crashed on Intel hardware or higher layer callers to continue as if the IOMMU operation succeeded on AMD hardware.

An issue was discovered in Xen where a guest may access xenstore paths via absolute paths containing a full pathname, or via a relative path, which implicitly includes `/local/domain/$DOMID` for their own domain id. Management tools must access paths in guests' namespaces, necessarily using absolute paths. oxenstored imposes a pathname limit that is applied solely to the relative or absolute path specified by the client. Therefore, a guest can create paths in its own namespace which are too long for management tools to access. Depending on the toolstack in use, a malicious guest administrator might cause some management tools and debugging operations to fail. For example, a guest administrator can cause "xenstore-ls -r" to fail. However, a guest administrator cannot prevent the host administrator from tearing down the domain. All systems using oxenstored are vulnerable.