Roger Pau

x86 PV guests can free memory pages while maintaining a stale TLB (Translation Lookaside Buffer) entry pointing to them. A TLB flush is only issued by Xen when the page is re-used. Because a page can be scrubbed before the TLB flush occurs, a window exists where a PV guest can modify a page that has already been scrubbed.

Certain shadow paging error paths switch page-tables without updating the currently running vCPU reference. This creates a mismatch between the loaded page-tables and the mapcache metadata, which can result in the corruption of the mapcache.

The Intel EPT paging code includes an optimization that defers flushing of cached EPT state until the p2m lock is released. However, the freeing of paging structures is not deferred, potentially leading to stale entries pointing to memory regions not owned by the guest. This can allow access to unintended memory regions. The issue may allow privileged code in a guest virtual machine to compromise the host system.

Name of the Vulnerable Software and Affected Versions: The product name cannot be determined. (affected versions not specified) **Description** The vulnerability is awaiting analysis. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

The issue concerns a cross-platform hypervisor, Xen, within the Linux operating system kernel. It relates to synchronization errors when a shared resource is used, and a race condition during the mapping of a Time Stamp Counter (TSC) reference page. Successful exploitation may allow a remote attacker to compromise the hypervisor or the vulnerable system.

The vulnerability is awaiting analysis.

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 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 is related to a disclosure of information in the Xen hypervisor and Linux kernel. It may allow a remote attacker to gain unauthorized access to protected information.

The issue is related to a disclosure of information in the Xen hypervisor Linux kernel. It may allow a remote attacker to gain unauthorized access to protected information.

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.