Roger Pau Monné

The issue arises from a mismatch in the IOMMU quarantine page table levels. On systems with no RAM above the 512GB mark, only 3 page-table levels are configured in the IOMMU, while the quarantine domain is initialized with 4 page table levels. This results in a device in quarantine mode gaining write access to the page destined to be a PDE, potentially leading to data leaks. The sink page the device gets read/write access to is no longer cleared between device assignment.

The caching invalidation guidelines from the AMD-Vi specification are incorrect on some hardware, leading to devices malfunctioning if some fields of the DTE are updated but the IOMMU TLB is not flushed. This can cause stale DMA mappings, allowing access to unintended memory regions not owned by the guest.

The issue is related to the functionality of phantom functions in PCI devices, which can generate requests using the IDs of unpopulated functions, allowing a device to extend the number of outstanding requests. However, failure to set up the IOMMU context for these phantom functions is not fatal when the device is assigned, leading to potential security issues. This can result in the primary device being assigned to a guest, while some phantom functions are assigned to a different domain. The vulnerability is related to insufficient access control due to incorrect input validation when generating requests.

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. Due to insufficient checks in hypervisor routines for shadow page handling, a guest with a passed-through PCI device can cause the hypervisor to access an arbitrary pointer partially under guest control.

The issue concerns the storage of PLC passwords in plain text within the configuration file of the CODESYS OPC DA Server, making these passwords visible to all authorized Microsoft Windows users of the system.

The issue is related to information disclosure in the Xen hypervisor and Linux kernel. It may allow an attacker to gain unauthorized access to protected information or cause a denial of service.

The issue is related to information disclosure in the Xen hypervisor and Linux kernel. It may allow an attacker to gain unauthorized access to protected information or cause a denial of service.

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.

The issue arises from racy interactions between dirty vram tracking and paging log dirty hypercalls. Activation of log dirty mode done by `XEN DMOP track dirty vram` (previously named `HVMOP track dirty vram` before Xen 4.9) is racy with ongoing log dirty hypercalls. A suitably timed call to `XEN DMOP track dirty vram` can enable log dirty while another CPU is still in the process of tearing down the structures related to a previously enabled log dirty mode (`XEN DOMCTL SHADOW OP OFF`). This is due to the lack of mutually exclusive locking between both operations and can lead to entries being added in already freed slots, resulting in a memory leak.

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 concerns IOMMU (Input-Output Memory Management Unit) handling problems related to RMRR (Reserved Memory Region Reporting) for Intel VT-d and Unity Mapping ranges for AMD-Vi. Certain PCI devices might be assigned Reserved Memory Regions for platform tasks like legacy USB emulation. Since the purpose of these regions is unknown, their mappings need to remain accessible by the device once it's active. However, this requirement has been violated, potentially leading to unpredictable behavior, including IOMMU faults and memory corruption.

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.

An issue was discovered in Xen when moving IRQs between CPUs to distribute the load of IRQ handling. IRQ vectors are dynamically allocated and de-allocated on the relevant CPUs. De-allocation has to happen when certain constraints are met. If these conditions are not met when first checked, the checking CPU may send an interrupt to itself, in the expectation that this IRQ will be delivered only after the condition preventing the cleanup has cleared. For two specific IRQ vectors, this expectation was violated, resulting in a continuous stream of self-interrupts, which renders the CPU effectively unusable. A domain with a passed through PCI device can cause lockup of a physical CPU, resulting in a Denial of Service (DoS) to the entire host. Only x86 systems are vulnerable, while Arm systems are not. The issue can be exploited by guests with physical PCI devices passed through to them.

The issue allows x86 Intel HVM guest OS users to cause a host OS denial of service or possibly gain privileges because of insufficient cache write-back under VT-d. When page tables are shared between IOMMU and CPU, changes to them require flushing of both TLBs. Furthermore, IOMMUs may be non-coherent, and hence prior to flushing IOMMU TLBs, a CPU cache also needs writing back to memory after changes were made. A malicious guest may be able to retain read/write DMA access to frames returned to Xen's free pool, and later reused for another purpose. Host crashes and privilege escalation cannot be ruled out. Only x86 Intel systems are affected, and only x86 HVM guests using hardware assisted paging (HAP), having a passed through PCI device assigned, and having page table sharing enabled can leverage the vulnerability.

An issue allows x86 HVM guest OS users to cause a denial of service or possibly gain hypervisor privileges by setting up an HPET timer to deliver interrupts in IO-APIC mode. This can lead to an unexpectedly high interrupt number, array overrun, and hypervisor crash.

An issue allows x86 HVM guest OS users to obtain sensitive information from the host OS or an arbitrary guest OS. This occurs because intercepted I/O operations can cause a write of data from uninitialized hypervisor stack memory.

The issue is related to the `do mmu update` function in `arch/x86/mm.c`, which does not properly restrict updates to only PV page tables. This allows remote PV guests to cause a denial of service (NULL pointer dereference) by leveraging hardware emulation services for HVM guests using Hardware Assisted Paging (HAP).