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.

تتطلب عمليات الوصول إلى منافذ الإدخال/الإخراج (I/O) للضيف في بيئة HVM إما محاكاة أو ترجمة. وتتم إدارة عمليات الترجمة هذه بواسطة نموذج الجهاز من خلال ’XEN DOMCTL ioport mapping‘. يمكن أن تتغير القائمة المرتبطة المستخدمة لهذه الترجمات في أي وقت، لكن عملية مسح هذه القوائم أثناء معالجة الوصول إلى منافذ الإدخال/الإخراج للضيف كانت تفتقر إلى التزامن اللازم مع التحديثات.

تتعلق المشكلة ببرنامج «هايبيرفيزور» متعدد المنصات، وهو Xen، الموجود ضمن نواة نظام التشغيل Linux. وترتبط هذه المشكلة بثغرات في التحكم في الوصول والتنفيذ غير السليم لقفل P2M عند الحصول على مراجع الصفحات. وقد يؤدي الاستغلال الناجح لهذه الثغرة إلى تمكين مهاجم عن بُعد من الوصول إلى معلومات سرية.

تتعلق المشكلة برمز التتبع في وضع «shadow» الذي يستخدم متغيرات لكل وحدة معالجة مركزية (CPU) لتحسين تمرير المعلمات. تُكتب بعض المتغيرات باستخدام بيانات يتحكم فيها الضيف، ويحدد الضيف نفسه حجمها. قد يتجاوز هذا الحجم سعة المتغير، ولا توجد عملية التحقق من الحدود اللازمة. قد يؤدي ذلك إلى تلف الذاكرة إذا استغل ضيف ضار هذه الثغرة. يتطلب استغلال هذه المشكلة اختراق الضيف.

يوجد عيب في برنامج Xen hypervisor الخاص بنواة نظام التشغيل Linux يتعلق بإلغاء مرجعية مؤشر فارغ. تحدث هذه المشكلة أثناء تعيين الصفحات التي تنتمي إلى مجالات أخرى. قد يؤدي الاستغلال الناجح لهذا العيب إلى تمكين مهاجم عن بُعد من التسبب في حجب الخدمة.

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.