Citrix Xen Virtualization Software
Don't miss out!
Thousands of developers use stack.watch to stay informed.Get an email whenever new security vulnerabilities are reported in any Citrix Xen product.
RSS Feeds for Citrix Xen security vulnerabilities
Create a CVE RSS feed including security vulnerabilities found in Citrix Xen products with stack.watch. Just hit watch, then grab your custom RSS feed url.
Products by Citrix Xen Sorted by Most Security Vulnerabilities since 2018
By the Year
In 2025 there have been 0 vulnerabilities in Citrix Xen. Last year, in 2024 Citrix Xen had 14 security vulnerabilities published. Right now, Citrix Xen is on track to have less security vulnerabilities in 2025 than it did last year.
Year | Vulnerabilities | Average Score |
---|---|---|
2025 | 0 | 0.00 |
2024 | 14 | 5.60 |
2023 | 14 | 6.66 |
2022 | 57 | 6.53 |
2021 | 27 | 6.96 |
2020 | 44 | 6.49 |
2019 | 25 | 7.28 |
2018 | 27 | 7.39 |
It may take a day or so for new Citrix Xen vulnerabilities to show up in the stats or in the list of recent security vulnerabilties. Additionally vulnerabilities may be tagged under a different product or component name.
Recent Citrix Xen Security Vulnerabilities
Xen Hypervisor VGA Memory Access Deadlock Vulnerability
CVE-2024-45818
- December 19, 2024
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.
Xen Hypervisor ACPI Table Construction Information Disclosure Vulnerability
CVE-2024-45819
- December 19, 2024
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.
Recent x86 CPUs offer functionality named Control-flow Enforcement
Technology (CET)
CVE-2023-46841
- March 20, 2024
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.
When a transaction is committed, C Xenstored will first check
the quota is correct before attempting to commit any nodes
CVE-2023-34323
5.5 - Medium
- January 05, 2024
When a transaction is committed, C Xenstored will first check the quota is correct before attempting to commit any nodes. It would be possible that accounting is temporarily negative if a node has been removed outside of the transaction. Unfortunately, some versions of C Xenstored are assuming that the quota cannot be negative and are using assert() to confirm it. This will lead to C Xenstored crash when tools are built without -DNDEBUG (this is the default).
NULL Pointer Dereference
The fixes for XSA-422 (Branch Type Confusion) and XSA-434 (Speculative
Return Stack Overflow) are not IRQ-safe
CVE-2023-46836
4.7 - Medium
- January 05, 2024
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.
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE
CVE-2023-34328
5.5 - Medium
- January 05, 2024
[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.
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE
CVE-2023-34327
5.5 - Medium
- January 05, 2024
[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.
The caching invalidation guidelines
CVE-2023-34326
7.8 - High
- January 05, 2024
The caching invalidation guidelines from the AMD-Vi specification (48882Rev 3.07-PUBOct 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.
Closing of an event channel in the Linux kernel can result in a deadlock
CVE-2023-34324
4.9 - Medium
- January 05, 2024
Closing of an event channel in the Linux kernel can result in a deadlock. This happens when the close is being performed in parallel to an unrelated Xen console action and the handling of a Xen console interrupt in an unprivileged guest. The closing of an event channel is e.g. triggered by removal of a paravirtual device on the other side. As this action will cause console messages to be issued on the other side quite often, the chance of triggering the deadlock is not neglectable. Note that 32-bit Arm-guests are not affected, as the 32-bit Linux kernel on Arm doesn't use queued-RW-locks, which are required to trigger the issue (on Arm32 a waiting writer doesn't block further readers to get the lock).
Resource Exhaustion
[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE
CVE-2023-34325
7.8 - High
- January 05, 2024
[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 grubs 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.
Memory Corruption