Jan Beulich

During the termination of guests, the cleanup of assigned PCI devices and the removal of tracking structures for Interrupt Requests (IRQs) occur early in the process. A guest being terminated can cause its device model (DM) to re-establish these tracking structures by binding one or more IRQs anew, resulting in at least one tracking structure failing to be cleaned up.

This update for xen fixes the following issues: Update to version 4.20.3 (jsc#PED-8907). Security issues fixed: - CVE-2026-42493: x86 shadow paging is deprecated (bsc#1271528). - CVE-2026-42494,CVE-2026-42495,CVE-2026-62423,CVE-2026-62424,CVE-2026-62425: buffer overruns in libfsimage iso9660 handling (bsc#1271530). - CVE-2026-62426,CVE-2026-62427: sysctl and platform-op locks open to abuse (bsc#1271531). - CVE-2026-62428: grant-table: type confusion in grant-copy (bsc#1271532). - CVE-2026-62429: vNUMA domain cleanup may race other operations (bsc#1271534). - CVE-2026-62430: x86: Out-of-bounds read in vRTC emulation (bsc#1271535). - CVE-2026-62431: Viridian STIMER division by zero (bsc#1271536). - CVE-2026-62432: evtchn: Race between FIFO expand and reset (bsc#1271537). - CVE-2026-62433: correct buffer checks for DM OP hypercalls (bsc#1271538). - CVE-2026-62434: PoD: Don't try to reclaim special pages (bsc#1271539). - CVE-2026-62437: x86: DMs may cause mem leak by IRQ binding (bsc#1276838). - CVE-2026-79602: x86: improper handling of HVM emulation return codes (bsc#1276839). - CVE-2026-79603: unconditionally do TLB flushing ahead of page scrubbing (bsc#1276841). - pygrub is only supported in de-privileged mode (bsc#1271947). Non security issue fixed: - Xen: Missing upstream bug fixes (bsc#1027519).

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

HVM guest I/O port accesses require either emulation or translation. These translations are managed by the device model through 'XEN DOMCTL ioport mapping'. The linked list used for these translations can change at any time, but the traversal of these lists during guest I/O port access handling lacked the necessary synchronization with updates.

The issue concerns a cross-platform hypervisor, Xen, within the Linux operating system kernel. It relates to flaws in access control and improper implementation of P2M locking when obtaining page references. Successful exploitation may allow a remote attacker to gain access to confidential information.

The issue involves shadow mode tracing code that utilizes per-CPU variables to streamline parameter passing. Certain variables are written to using guest-controlled data of a size determined by the guest. This size can exceed the variable's capacity, and the necessary bounds checking is absent. This can lead to memory corruption if a malicious guest exploits this flaw. The issue requires guest compromise to be exploited.

A flaw exists in the Xen hypervisor for the Linux operating system kernel related to a null pointer dereference. This issue occurs during page mapping of pages belonging to other domains. Successful exploitation could allow a remote attacker to cause a denial of service.

The issue is related to flawed error handling in the logic establishing mappings for Reserved Memory Regions (RMRR) in Intel VT-d or Unity Mapping ranges for AMD-Vi. This flaw can result in mappings remaining in place when they should have been removed, allowing respective guests to gain access to memory regions they are not supposed to have access to. The precise purpose of these regions is unknown, and they are typically used for platform tasks such as legacy USB emulation.

The issue concerns an optional feature of PCI MSI called "Multiple Message" that allows a device to use multiple consecutive interrupt vectors. Unlike for MSI-X, the setting up of these consecutive vectors needs to happen all in one go. In this handling, an error path could be taken in different situations, with or without a particular lock held. This error path wrongly releases the lock even when it is not currently held.

The issue is related to the interaction between the Control-flow Enforcement Technology (CET) and the Xen emulation. CET is a hardware feature designed to protect against Return Oriented Programming attacks, and it uses Shadow Stacks (CET-SS) to store return addresses. When certain memory accesses need to be intercepted by Xen, the necessary emulation involves replaying the instruction, which may raise exceptions. However, the recovery process involves removing a call frame from the traditional stack, but the counterpart operation for the shadow stack is missing. This can cause a hypervisor crash, leading to a Denial of Service (DoS) of the entire host.

The issue arises when PV guests are run in shadow paging mode to work around kernels unaware of L1TF. In this mode, Xen and shadowed PV guests run directly on the respective shadow page tables. For 64-bit PV guests, this means running on the shadow of the guest root page table. When dealing with a shortage of memory in the shadow pool associated with a domain, shadows of page tables may be torn down, including the shadow root page table that the CPU is presently running on. A precaution exists to prevent the tearing down of the underlying live page table, but the time window covered by this precaution is not large enough.

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

The issue arises in environments where host-assisted address translation is necessary but Hardware Assisted Paging (HAP) is unavailable, causing Xen to run guests in shadow mode. Shadow mode maintains a pool of memory for shadow page tables and auxiliary data structures. When migrating or snapshotting guests, Xen also runs them in log-dirty mode, which requires additional data structures. However, the demands of the log-dirty infrastructure were not considered, leading to a situation where newly established shadow page tables could be freed immediately, while other code is still accessing them. This results in a use-after-free scenario.

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 lock order inversion in transitive grant copy handling. This occurred after a missing cleanup call was inserted on an error handling path as part of XSA-226, without considering locking requirements. As a result, two cooperating guests granting each other transitive grants can cause locks to be acquired in a nested manner but in opposite order. With suitable timing between the involved grant copy operations, this may result in the locking up of a CPU.

The issue is related to insufficient input validation in the Xen hypervisor and Linux kernel, which can be exploited by a remote attacker to execute arbitrary code. The problem lies in the network backend, where a code change to support XDP (eXpress Data Path) allowed SKBs (socket buffers) with retained references to be freed, potentially causing Linux netfront to use freed SKBs.

The issue concerns IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling problems. Certain PCI devices in a system might be assigned Reserved Memory Regions for Intel VT-d or Unity Mapping ranges for AMD-Vi, typically used for platform tasks such as legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with such a region is active, the mappings of these regions need to remain continuously accessible by the device. This requirement has been violated, potentially leading to unpredictable behavior, ranging from IOMMU faults to memory corruption.

A race condition exists in the VT-d domain ID cleanup process. Xen domain IDs are up to 15 bits wide, but VT-d hardware may only support less than 15 bits to hold a domain ID, associating a physical device with a particular domain. As a result, Xen domain IDs are mapped to a smaller value range internally. The cleaning up of housekeeping structures has a race, allowing VT-d domain IDs to be leaked and flushes to be bypassed.

The issue concerns IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling issues. Certain PCI devices in a system might be assigned Reserved Memory Regions for Intel VT-d or Unity Mapping ranges for AMD-Vi, typically used for platform tasks such as legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with such a region is active, the mappings of these regions need to remain continuously accessible by the device. This requirement has been violated, resulting in unpredictable behavior, ranging from IOMMU faults to memory corruption, when subsequent DMA or interrupts from the device occur.

The issue relates to IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling issues. Certain PCI devices in a system might be assigned Reserved Memory Regions for Intel VT-d or Unity Mapping ranges for AMD-Vi, typically used for platform tasks such as legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with such a region is active, the mappings of these regions need to remain continuously accessible by the device. This requirement has been violated, resulting in unpredictable behavior, ranging from IOMMU faults to memory corruption.