Total
493 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-1713 | 1 Xen | 1 Xen | 2026-06-17 | N/A | 7.5 HIGH |
| When setting up interrupt remapping for legacy PCI(-X) devices, including PCI(-X) bridges, a lookup of the upstream bridge is required. This lookup, itself involving acquiring of a lock, is done in a context where acquiring that lock is unsafe. This can lead to a deadlock. | |||||
| CVE-2024-45819 | 1 Xen | 1 Xen | 2026-06-17 | N/A | 5.5 MEDIUM |
| PVH guests have their ACPI tables constructed by the toolstack. The construction involves building the tables in local memory, which are then copied into guest memory. While actually used parts of the local memory are filled in correctly, excess space that is being allocated is left with its prior contents. | |||||
| CVE-2024-45818 | 1 Xen | 1 Xen | 2026-06-17 | N/A | 6.5 MEDIUM |
| The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in "standard" mode. Locking involved there has an unusual discipline, leaving a lock acquired past the return from the function that acquired it. This behavior results in a problem when emulating an instruction with two memory accesses, both of which touch VGA memory (plus some further constraints which aren't relevant here). When emulating the 2nd access, the lock that is already being held would be attempted to be re-acquired, resulting in a deadlock. This deadlock was already found when the code was first introduced, but was analysed incorrectly and the fix was incomplete. Analysis in light of the new finding cannot find a way to make the existing locking discipline work. In staging, this logic has all been removed because it was discovered to be accidentally disabled since Xen 4.7. Therefore, we are fixing the locking problem by backporting the removal of most of the feature. Note that even with the feature disabled, the lock would still be acquired for any accesses to the VGA MMIO region. | |||||
| CVE-2024-45817 | 1 Xen | 1 Xen | 2026-06-17 | N/A | 7.3 HIGH |
| In x86's APIC (Advanced Programmable Interrupt Controller) architecture, error conditions are reported in a status register. Furthermore, the OS can opt to receive an interrupt when a new error occurs. It is possible to configure the error interrupt with an illegal vector, which generates an error when an error interrupt is raised. This case causes Xen to recurse through vlapic_error(). The recursion itself is bounded; errors accumulate in the the status register and only generate an interrupt when a new status bit becomes set. However, the lock protecting this state in Xen will try to be taken recursively, and deadlock. | |||||
| CVE-2024-31146 | 1 Xen | 1 Xen | 2026-06-17 | N/A | 7.5 HIGH |
| When multiple devices share resources and one of them is to be passed through to a guest, security of the entire system and of respective guests individually cannot really be guaranteed without knowing internals of any of the involved guests. Therefore such a configuration cannot really be security-supported, yet making that explicit was so far missing. Resources the sharing of which is known to be problematic include, but are not limited to - - PCI Base Address Registers (BARs) of multiple devices mapping to the same page (4k on x86), - - INTx lines. | |||||
| CVE-2024-31145 | 1 Xen | 1 Xen | 2026-06-17 | N/A | 7.5 HIGH |
| Certain PCI devices in a system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, "RMRR") for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are 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 continuouly accessible by the device. In the logic establishing these mappings, error handling was flawed, resulting in such mappings to potentially remain in place when they should have been removed again. Respective guests would then gain access to memory regions which they aren't supposed to have access to. | |||||
| CVE-2024-31143 | 1 Xen | 1 Xen | 2026-06-17 | N/A | 7.5 HIGH |
| An optional feature of PCI MSI called "Multiple Message" 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. | |||||
| CVE-2024-31142 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2026-06-17 | N/A | 7.5 HIGH |
| Because of a logical error in XSA-407 (Branch Type Confusion), the mitigation is not applied properly when it is intended to be used. XSA-434 (Speculative Return Stack Overflow) uses the same infrastructure, so is equally impacted. For more details, see: https://xenbits.xen.org/xsa/advisory-407.html https://xenbits.xen.org/xsa/advisory-434.html | |||||
| CVE-2023-4949 | 2 Gnu, Xen | 2 Grub, Xen | 2026-06-17 | N/A | 8.1 HIGH |
| An attacker with local access to a system (either through a disk or external drive) can present a modified XFS partition to grub-legacy in such a way to exploit a memory corruption in grub’s XFS file system implementation. | |||||
| CVE-2023-46842 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2026-06-17 | N/A | 6.5 MEDIUM |
| Unlike 32-bit PV guests, HVM guests may switch freely between 64-bit and other modes. This in particular means that they may set registers used to pass 32-bit-mode hypercall arguments to values outside of the range 32-bit code would be able to set them to. When processing of hypercalls takes a considerable amount of time, the hypervisor may choose to invoke a hypercall continuation. Doing so involves putting (perhaps updated) hypercall arguments in respective registers. For guests not running in 64-bit mode this further involves a certain amount of translation of the values. Unfortunately internal sanity checking of these translated values assumes high halves of registers to always be clear when invoking a hypercall. When this is found not to be the case, it triggers a consistency check in the hypervisor and causes a crash. | |||||
| CVE-2023-46841 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2026-06-17 | N/A | 6.5 MEDIUM |
| Recent x86 CPUs offer functionality named Control-flow Enforcement Technology (CET). A sub-feature of this are Shadow Stacks (CET-SS). CET-SS is a hardware feature designed to protect against Return Oriented Programming attacks. When enabled, traditional stacks holding both data and return addresses are accompanied by so called "shadow stacks", holding little more than return addresses. Shadow stacks aren't writable by normal instructions, and upon function returns their contents are used to check for possible manipulation of a return address coming from the traditional stack. In particular certain memory accesses need intercepting by Xen. In various cases the necessary emulation involves kind of replaying of the instruction. Such replaying typically involves filling and then invoking of a stub. Such a replayed instruction may raise an exceptions, which is expected and dealt with accordingly. Unfortunately the interaction of both of the above wasn't right: Recovery involves removal of a call frame from the (traditional) stack. The counterpart of this operation for the shadow stack was missing. | |||||
| CVE-2023-46840 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2026-06-17 | N/A | 4.1 MEDIUM |
| Incorrect placement of a preprocessor directive in source code results in logic that doesn't operate as intended when support for HVM guests is compiled out of Xen. | |||||
| CVE-2023-46839 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2026-06-17 | N/A | 5.3 MEDIUM |
| PCI devices can make use of a functionality called phantom functions, that when enabled allows the device to generate requests using the IDs of functions that are otherwise unpopulated. This allows a device to extend the number of outstanding requests. Such phantom functions need an IOMMU context setup, but failure to setup the context is not fatal when the device is assigned. Not failing device assignment when such failure happens can lead to the primary device being assigned to a guest, while some of the phantom functions are assigned to a different domain. | |||||
| CVE-2023-46837 | 1 Xen | 1 Xen | 2026-06-17 | N/A | 3.3 LOW |
| Arm provides multiple helpers to clean & invalidate the cache for a given region. This is, for instance, used when allocating guest memory to ensure any writes (such as the ones during scrubbing) have reached memory before handing over the page to a guest. Unfortunately, the arithmetics in the helpers can overflow and would then result to skip the cache cleaning/invalidation. Therefore there is no guarantee when all the writes will reach the memory. This undefined behavior was meant to be addressed by XSA-437, but the approach was not sufficient. | |||||
| CVE-2023-46836 | 1 Xen | 1 Xen | 2026-06-17 | N/A | 4.7 MEDIUM |
| The fixes for XSA-422 (Branch Type Confusion) and XSA-434 (Speculative Return Stack Overflow) are not IRQ-safe. It was believed that the mitigations always operated in contexts with IRQs disabled. However, the original XSA-254 fix for Meltdown (XPTI) deliberately left interrupts enabled on two entry paths; one unconditionally, and one conditionally on whether XPTI was active. As BTC/SRSO and Meltdown affect different CPU vendors, the mitigations are not active together by default. Therefore, there is a race condition whereby a malicious PV guest can bypass BTC/SRSO protections and launch a BTC/SRSO attack against Xen. | |||||
| CVE-2023-46835 | 1 Xen | 1 Xen | 2026-06-17 | N/A | 5.5 MEDIUM |
| The current setup of the quarantine page tables assumes that the quarantine domain (dom_io) has been initialized with an address width of DEFAULT_DOMAIN_ADDRESS_WIDTH (48) and hence 4 page table levels. However dom_io being a PV domain gets the AMD-Vi IOMMU page tables levels based on the maximum (hot pluggable) RAM address, and hence on systems with no RAM above the 512GB mark only 3 page-table levels are configured in the IOMMU. On systems without RAM above the 512GB boundary amd_iommu_quarantine_init() will setup page tables for the scratch page with 4 levels, while the IOMMU will be configured to use 3 levels only, resulting in the last page table directory (PDE) effectively becoming a page table entry (PTE), and hence a device in quarantine mode gaining write access to the page destined to be a PDE. Due to this page table level mismatch, the sink page the device gets read/write access to is no longer cleared between device assignment, possibly leading to data leaks. | |||||
| CVE-2023-34328 | 1 Xen | 1 Xen | 2026-06-17 | N/A | 5.5 MEDIUM |
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] AMD CPUs since ~2014 have extensions to normal x86 debugging functionality. Xen supports guests using these extensions. Unfortunately there are errors in Xen's handling of the guest state, leading to denials of service. 1) CVE-2023-34327 - An HVM vCPU can end up operating in the context of a previous vCPUs debug mask state. 2) CVE-2023-34328 - A PV vCPU can place a breakpoint over the live GDT. This allows the PV vCPU to exploit XSA-156 / CVE-2015-8104 and lock up the CPU entirely. | |||||
| CVE-2023-34327 | 1 Xen | 1 Xen | 2026-06-17 | N/A | 5.5 MEDIUM |
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] AMD CPUs since ~2014 have extensions to normal x86 debugging functionality. Xen supports guests using these extensions. Unfortunately there are errors in Xen's handling of the guest state, leading to denials of service. 1) CVE-2023-34327 - An HVM vCPU can end up operating in the context of a previous vCPUs debug mask state. 2) CVE-2023-34328 - A PV vCPU can place a breakpoint over the live GDT. This allows the PV vCPU to exploit XSA-156 / CVE-2015-8104 and lock up the CPU entirely. | |||||
| CVE-2023-34326 | 1 Xen | 1 Xen | 2026-06-17 | N/A | 7.8 HIGH |
| The caching invalidation guidelines from the AMD-Vi specification (48882—Rev 3.07-PUB—Oct 2022) is incorrect on some hardware, as devices will malfunction (see stale DMA mappings) if some fields of the DTE are updated but the IOMMU TLB is not flushed. Such stale DMA mappings can point to memory ranges not owned by the guest, thus allowing access to unindented memory regions. | |||||
| CVE-2023-34325 | 1 Xen | 1 Xen | 2026-06-17 | N/A | 7.8 HIGH |
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] libfsimage contains parsing code for several filesystems, most of them based on grub-legacy code. libfsimage is used by pygrub to inspect guest disks. Pygrub runs as the same user as the toolstack (root in a priviledged domain). At least one issue has been reported to the Xen Security Team that allows an attacker to trigger a stack buffer overflow in libfsimage. After further analisys the Xen Security Team is no longer confident in the suitability of libfsimage when run against guest controlled input with super user priviledges. In order to not affect current deployments that rely on pygrub patches are provided in the resolution section of the advisory that allow running pygrub in deprivileged mode. CVE-2023-4949 refers to the original issue in the upstream grub project ("An attacker with local access to a system (either through a disk or external drive) can present a modified XFS partition to grub-legacy in such a way to exploit a memory corruption in grub’s XFS file system implementation.") CVE-2023-34325 refers specifically to the vulnerabilities in Xen's copy of libfsimage, which is decended from a very old version of grub. | |||||