Filtered by vendor Xen
Subscribe
Search
Total
135 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2020-29566 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2021-12-10 | 4.9 MEDIUM | 5.5 MEDIUM |
| An issue was discovered in Xen through 4.14.x. When they require assistance from the device model, x86 HVM guests must be temporarily de-scheduled. The device model will signal Xen when it has completed its operation, via an event channel, so that the relevant vCPU is rescheduled. If the device model were to signal Xen without having actually completed the operation, the de-schedule / re-schedule cycle would repeat. If, in addition, Xen is resignalled very quickly, the re-schedule may occur before the de-schedule was fully complete, triggering a shortcut. This potentially repeating process uses ordinary recursive function calls, and thus could result in a stack overflow. A malicious or buggy stubdomain serving a HVM guest can cause Xen to crash, resulting in a Denial of Service (DoS) to the entire host. Only x86 systems are affected. Arm systems are not affected. Only x86 stubdomains serving HVM guests can exploit the vulnerability. | |||||
| CVE-2020-29571 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2021-12-10 | 4.9 MEDIUM | 6.2 MEDIUM |
| An issue was discovered in Xen through 4.14.x. A bounds check common to most operation time functions specific to FIFO event channels depends on the CPU observing consistent state. While the producer side uses appropriately ordered writes, the consumer side isn't protected against re-ordered reads, and may hence end up de-referencing a NULL pointer. Malicious or buggy guest kernels can mount a Denial of Service (DoS) attack affecting the entire system. Only Arm systems may be vulnerable. Whether a system is vulnerable depends on the specific CPU. x86 systems are not vulnerable. | |||||
| CVE-2020-29567 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2021-12-10 | 4.9 MEDIUM | 6.2 MEDIUM |
| An issue was discovered in Xen 4.14.x. 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. Arm systems are not vulnerable. Only guests with physical PCI devices passed through to them can exploit the vulnerability. | |||||
| CVE-2020-29486 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2021-12-10 | 4.9 MEDIUM | 6.0 MEDIUM |
| An issue was discovered in Xen through 4.14.x. Nodes in xenstore have an ownership. In oxenstored, a owner could give a node away. However, node ownership has quota implications. Any guest can run another guest out of quota, or create an unbounded number of nodes owned by dom0, thus running xenstored out of memory A malicious guest administrator can cause a denial of service against a specific guest or against the whole host. All systems using oxenstored are vulnerable. Building and using oxenstored is the default in the upstream Xen distribution, if the Ocaml compiler is available. Systems using C xenstored are not vulnerable. | |||||
| CVE-2021-26313 | 6 Amd, Arm, Broadcom and 3 more | 11 Ryzen 5 5600x, Ryzen 7 2700x, Ryzen Threadripper 2990wx and 8 more | 2021-10-13 | 2.1 LOW | 5.5 MEDIUM |
| Potential speculative code store bypass in all supported CPU products, in conjunction with software vulnerabilities relating to speculative execution of overwritten instructions, may cause an incorrect speculation and could result in data leakage. | |||||
| CVE-2021-28700 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2021-09-24 | 6.8 MEDIUM | 4.9 MEDIUM |
| xen/arm: No memory limit for dom0less domUs The dom0less feature allows an administrator to create multiple unprivileged domains directly from Xen. Unfortunately, the memory limit from them is not set. This allow a domain to allocate memory beyond what an administrator originally configured. | |||||
| CVE-2021-28693 | 1 Xen | 1 Xen | 2021-09-21 | 2.1 LOW | 5.5 MEDIUM |
| xen/arm: Boot modules are not scrubbed The bootloader will load boot modules (e.g. kernel, initramfs...) in a temporary area before they are copied by Xen to each domain memory. To ensure sensitive data is not leaked from the modules, Xen must "scrub" them before handing the page over to the allocator. Unfortunately, it was discovered that modules will not be scrubbed on Arm. | |||||
| CVE-2021-28690 | 1 Xen | 1 Xen | 2021-09-21 | 4.0 MEDIUM | 6.5 MEDIUM |
| x86: TSX Async Abort protections not restored after S3 This issue relates to the TSX Async Abort speculative security vulnerability. Please see https://xenbits.xen.org/xsa/advisory-305.html for details. Mitigating TAA by disabling TSX (the default and preferred option) requires selecting a non-default setting in MSR_TSX_CTRL. This setting isn't restored after S3 suspend. | |||||
| CVE-2021-28687 | 1 Xen | 1 Xen | 2021-09-20 | 4.9 MEDIUM | 5.5 MEDIUM |
| HVM soft-reset crashes toolstack libxl requires all data structures passed across its public interface to be initialized before use and disposed of afterwards by calling a specific set of functions. Many internal data structures also require this initialize / dispose discipline, but not all of them. When the "soft reset" feature was implemented, the libxl__domain_suspend_state structure didn't require any initialization or disposal. At some point later, an initialization function was introduced for the structure; but the "soft reset" path wasn't refactored to call the initialization function. When a guest nwo initiates a "soft reboot", uninitialized data structure leads to an assert() when later code finds the structure in an unexpected state. The effect of this is to crash the process monitoring the guest. How this affects the system depends on the structure of the toolstack. For xl, this will have no security-relevant effect: every VM has its own independent monitoring process, which contains no state. The domain in question will hang in a crashed state, but can be destroyed by `xl destroy` just like any other non-cooperating domain. For daemon-based toolstacks linked against libxl, such as libvirt, this will crash the toolstack, losing the state of any in-progress operations (localized DoS), and preventing further administrator operations unless the daemon is configured to restart automatically (system-wide DoS). If crashes "leak" resources, then repeated crashes could use up resources, also causing a system-wide DoS. | |||||
| CVE-2019-17344 | 1 Xen | 1 Xen | 2021-07-21 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service by leveraging a long-running operation that exists to support restartability of PTE updates. | |||||
| CVE-2019-17345 | 1 Xen | 1 Xen | 2021-07-21 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen 4.8.x through 4.11.x allowing x86 PV guest OS users to cause a denial of service because mishandling of failed IOMMU operations causes a bug check during the cleanup of a crashed guest. | |||||
| CVE-2019-17343 | 1 Xen | 1 Xen | 2021-07-21 | 4.6 MEDIUM | 6.8 MEDIUM |
| An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service or gain privileges by leveraging incorrect use of the HVM physmap concept for PV domains. | |||||
| CVE-2020-29482 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2021-03-16 | 4.9 MEDIUM | 6.0 MEDIUM |
| An issue was discovered in Xen through 4.14.x. A guest may access xenstore paths via absolute paths containing a full pathname, or via a relative path, which implicitly includes /local/domain/$DOMID for their own domain id. Management tools must access paths in guests' namespaces, necessarily using absolute paths. oxenstored imposes a pathname limit that is applied solely to the relative or absolute path specified by the client. Therefore, a guest can create paths in its own namespace which are too long for management tools to access. Depending on the toolstack in use, a malicious guest administrator might cause some management tools and debugging operations to fail. For example, a guest administrator can cause "xenstore-ls -r" to fail. However, a guest administrator cannot prevent the host administrator from tearing down the domain. All systems using oxenstored are vulnerable. Building and using oxenstored is the default in the upstream Xen distribution, if the Ocaml compiler is available. Systems using C xenstored are not vulnerable. | |||||
| CVE-2020-29483 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2021-03-16 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS. | |||||
| CVE-2020-29484 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2021-03-16 | 4.9 MEDIUM | 6.0 MEDIUM |
| An issue was discovered in Xen through 4.14.x. When a Xenstore watch fires, the xenstore client that registered the watch will receive a Xenstore message containing the path of the modified Xenstore entry that triggered the watch, and the tag that was specified when registering the watch. Any communication with xenstored is done via Xenstore messages, consisting of a message header and the payload. The payload length is limited to 4096 bytes. Any request to xenstored resulting in a response with a payload longer than 4096 bytes will result in an error. When registering a watch, the payload length limit applies to the combined length of the watched path and the specified tag. Because watches for a specific path are also triggered for all nodes below that path, the payload of a watch event message can be longer than the payload needed to register the watch. A malicious guest that registers a watch using a very large tag (i.e., with a registration operation payload length close to the 4096 byte limit) can cause the generation of watch events with a payload length larger than 4096 bytes, by writing to Xenstore entries below the watched path. This will result in an error condition in xenstored. This error can result in a NULL pointer dereference, leading to a crash of xenstored. A malicious guest administrator can cause xenstored to crash, leading to a denial of service. Following a xenstored crash, domains may continue to run, but management operations will be impossible. Only C xenstored is affected, oxenstored is not affected. | |||||
| CVE-2020-29485 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2021-03-16 | 4.9 MEDIUM | 5.5 MEDIUM |
| An issue was discovered in Xen 4.6 through 4.14.x. When acting upon a guest XS_RESET_WATCHES request, not all tracking information is freed. A guest can cause unbounded memory usage in oxenstored. This can lead to a system-wide DoS. Only systems using the Ocaml Xenstored implementation are vulnerable. Systems using the C Xenstored implementation are not vulnerable. | |||||
| CVE-2020-25597 | 1 Xen | 1 Xen | 2020-11-11 | 6.1 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that an event channel, once valid, will not become invalid over the life time of a guest. However, operations like the resetting of all event channels may involve decreasing one of the bounds checked when determining validity. This may lead to bug checks triggering, crashing the host. An unprivileged guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only systems with untrusted guests permitted to create more than the default number of event channels are vulnerable. This number depends on the architecture and type of guest. For 32-bit x86 PV guests, this is 1023; for 64-bit x86 PV guests, and for all ARM guests, this number is 4095. Systems where untrusted guests are limited to fewer than this number are not vulnerable. Note that xl and libxl limit max_event_channels to 1023 by default, so systems using exclusively xl, libvirt+libxl, or their own toolstack based on libxl, and not explicitly setting max_event_channels, are not vulnerable. | |||||
| CVE-2020-25596 | 4 Debian, Fedoraproject, Opensuse and 1 more | 4 Debian Linux, Fedora, Leap and 1 more | 2020-11-11 | 2.1 LOW | 5.5 MEDIUM |
| An issue was discovered in Xen through 4.14.x. x86 PV guest kernels can experience denial of service via SYSENTER. The SYSENTER instruction leaves various state sanitization activities to software. One of Xen's sanitization paths injects a #GP fault, and incorrectly delivers it twice to the guest. This causes the guest kernel to observe a kernel-privilege #GP fault (typically fatal) rather than a user-privilege #GP fault (usually converted into SIGSEGV/etc.). Malicious or buggy userspace can crash the guest kernel, resulting in a VM Denial of Service. All versions of Xen from 3.2 onwards are vulnerable. Only x86 systems are vulnerable. ARM platforms are not vulnerable. Only x86 systems that support the SYSENTER instruction in 64bit mode are vulnerable. This is believed to be Intel, Centaur, and Shanghai CPUs. AMD and Hygon CPUs are not believed to be vulnerable. Only x86 PV guests can exploit the vulnerability. x86 PVH / HVM guests cannot exploit the vulnerability. | |||||
| CVE-2020-25598 | 3 Fedoraproject, Opensuse, Xen | 3 Fedora, Leap, Xen | 2020-11-11 | 2.1 LOW | 5.5 MEDIUM |
| An issue was discovered in Xen 4.14.x. There is a missing unlock in the XENMEM_acquire_resource error path. The RCU (Read, Copy, Update) mechanism is a synchronisation primitive. A buggy error path in the XENMEM_acquire_resource exits without releasing an RCU reference, which is conceptually similar to forgetting to unlock a spinlock. A buggy or malicious HVM stubdomain can cause an RCU reference to be leaked. This causes subsequent administration operations, (e.g., CPU offline) to livelock, resulting in a host Denial of Service. The buggy codepath has been present since Xen 4.12. Xen 4.14 and later are vulnerable to the DoS. The side effects are believed to be benign on Xen 4.12 and 4.13, but patches are provided nevertheless. The vulnerability can generally only be exploited by x86 HVM VMs, as these are generally the only type of VM that have a Qemu stubdomain. x86 PV and PVH domains, as well as ARM VMs, typically don't use a stubdomain. Only VMs using HVM stubdomains can exploit the vulnerability. VMs using PV stubdomains, or with emulators running in dom0, cannot exploit the vulnerability. | |||||
| CVE-2020-25602 | 1 Xen | 1 Xen | 2020-11-11 | 4.6 MEDIUM | 6.0 MEDIUM |
| An issue was discovered in Xen through 4.14.x. An x86 PV guest can trigger a host OS crash when handling guest access to MSR_MISC_ENABLE. When a guest accesses certain Model Specific Registers, Xen first reads the value from hardware to use as the basis for auditing the guest access. For the MISC_ENABLE MSR, which is an Intel specific MSR, this MSR read is performed without error handling for a #GP fault, which is the consequence of trying to read this MSR on non-Intel hardware. A buggy or malicious PV guest administrator can crash Xen, resulting in a host Denial of Service. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only Xen versions 4.11 and onwards are vulnerable. 4.10 and earlier are not vulnerable. Only x86 systems that do not implement the MISC_ENABLE MSR (0x1a0) are vulnerable. AMD and Hygon systems do not implement this MSR and are vulnerable. Intel systems do implement this MSR and are not vulnerable. Other manufacturers have not been checked. Only x86 PV guests can exploit the vulnerability. x86 HVM/PVH guests cannot exploit the vulnerability. | |||||
| CVE-2020-25604 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2020-11-11 | 1.9 LOW | 4.7 MEDIUM |
| An issue was discovered in Xen through 4.14.x. There is a race condition when migrating timers between x86 HVM vCPUs. When migrating timers of x86 HVM guests between its vCPUs, the locking model used allows for a second vCPU of the same guest (also operating on the timers) to release a lock that it didn't acquire. The most likely effect of the issue is a hang or crash of the hypervisor, i.e., a Denial of Service (DoS). All versions of Xen are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only x86 HVM guests can leverage the vulnerability. x86 PV and PVH cannot leverage the vulnerability. Only guests with more than one vCPU can exploit the vulnerability. | |||||
| CVE-2019-18420 | 1 Xen | 1 Xen | 2020-08-24 | 6.3 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.12.x allowing x86 PV guest OS users to cause a denial of service via a VCPUOP_initialise hypercall. hypercall_create_continuation() is a variadic function which uses a printf-like format string to interpret its parameters. Error handling for a bad format character was done using BUG(), which crashes Xen. One path, via the VCPUOP_initialise hypercall, has a bad format character. The BUG() can be hit if VCPUOP_initialise executes for a sufficiently long period of time for a continuation to be created. Malicious guests may cause a hypervisor crash, resulting in a Denial of Service (DoS). Xen versions 4.6 and newer are vulnerable. Xen versions 4.5 and earlier are not vulnerable. Only x86 PV guests can exploit the vulnerability. HVM and PVH guests, and guests on ARM systems, cannot exploit the vulnerability. | |||||
| CVE-2019-17351 | 2 Linux, Xen | 2 Linux Kernel, Xen | 2020-08-24 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in drivers/xen/balloon.c in the Linux kernel before 5.2.3, as used in Xen through 4.12.x, allowing guest OS users to cause a denial of service because of unrestricted resource consumption during the mapping of guest memory, aka CID-6ef36ab967c7. | |||||
| CVE-2018-19964 | 1 Xen | 1 Xen | 2020-08-24 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen 4.11.x allowing x86 guest OS users to cause a denial of service (host OS hang) because the p2m lock remains unavailable indefinitely in certain error conditions. | |||||
| CVE-2020-11743 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2020-07-13 | 2.1 LOW | 5.5 MEDIUM |
| An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service because of a bad error path in GNTTABOP_map_grant. Grant table operations are expected to return 0 for success, and a negative number for errors. Some misplaced brackets cause one error path to return 1 instead of a negative value. The grant table code in Linux treats this condition as success, and proceeds with incorrectly initialised state. A buggy or malicious guest can construct its grant table in such a way that, when a backend domain tries to map a grant, it hits the incorrect error path. This will crash a Linux based dom0 or backend domain. | |||||
| CVE-2020-11742 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2020-07-13 | 2.1 LOW | 5.5 MEDIUM |
| An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service because of bad continuation handling in GNTTABOP_copy. Grant table operations are expected to return 0 for success, and a negative number for errors. The fix for CVE-2017-12135 introduced a path through grant copy handling where success may be returned to the caller without any action taken. In particular, the status fields of individual operations are left uninitialised, and may result in errant behaviour in the caller of GNTTABOP_copy. A buggy or malicious guest can construct its grant table in such a way that, when a backend domain tries to copy a grant, it hits the incorrect exit path. This returns success to the caller without doing anything, which may cause crashes or other incorrect behaviour. | |||||
| CVE-2019-19579 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2020-01-14 | 7.2 HIGH | 6.8 MEDIUM |
| An issue was discovered in Xen through 4.12.x allowing attackers to gain host OS privileges via DMA in a situation where an untrusted domain has access to a physical device (and assignable-add is not used), because of an incomplete fix for CVE-2019-18424. XSA-302 relies on the use of libxl's "assignable-add" feature to prepare devices to be assigned to untrusted guests. Unfortunately, this is not considered a strictly required step for device assignment. The PCI passthrough documentation on the wiki describes alternate ways of preparing devices for assignment, and libvirt uses its own ways as well. Hosts where these "alternate" methods are used will still leave the system in a vulnerable state after the device comes back from a guest. An untrusted domain with access to a physical device can DMA into host memory, leading to privilege escalation. Only systems where guests are given direct access to physical devices capable of DMA (PCI pass-through) are vulnerable. Systems which do not use PCI pass-through are not vulnerable. | |||||
| CVE-2019-19582 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2020-01-03 | 2.1 LOW | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.12.x allowing x86 guest OS users to cause a denial of service (infinite loop) because certain bit iteration is mishandled. In a number of places bitmaps are being used by the hypervisor to track certain state. Iteration over all bits involves functions which may misbehave in certain corner cases: On x86 accesses to bitmaps with a compile time known size of 64 may incur undefined behavior, which may in particular result in infinite loops. A malicious guest may cause a hypervisor crash or hang, resulting in a Denial of Service (DoS). All versions of Xen are vulnerable. x86 systems with 64 or more nodes are vulnerable (there might not be any such systems that Xen would run on). x86 systems with less than 64 nodes are not vulnerable. | |||||
| CVE-2019-19581 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2020-01-03 | 2.1 LOW | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.12.x allowing 32-bit Arm guest OS users to cause a denial of service (out-of-bounds access) because certain bit iteration is mishandled. In a number of places bitmaps are being used by the hypervisor to track certain state. Iteration over all bits involves functions which may misbehave in certain corner cases: On 32-bit Arm accesses to bitmaps with bit a count which is a multiple of 32, an out of bounds access may occur. A malicious guest may cause a hypervisor crash or hang, resulting in a Denial of Service (DoS). All versions of Xen are vulnerable. 32-bit Arm systems are vulnerable. 64-bit Arm systems are not vulnerable. | |||||
| CVE-2019-19580 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2020-01-03 | 6.0 MEDIUM | 6.6 MEDIUM |
| An issue was discovered in Xen through 4.12.x allowing x86 PV guest OS users to gain host OS privileges by leveraging race conditions in pagetable promotion and demotion operations, because of an incomplete fix for CVE-2019-18421. XSA-299 addressed several critical issues in restartable PV type change operations. Despite extensive testing and auditing, some corner cases were missed. A malicious PV guest administrator may be able to escalate their privilege to that of the host. All security-supported versions of Xen are vulnerable. Only x86 systems are affected. Arm systems are not affected. Only x86 PV guests can leverage the vulnerability. x86 HVM and PVH guests cannot leverage the vulnerability. Note that these attacks require very precise timing, which may be difficult to exploit in practice. | |||||
| CVE-2019-18424 | 1 Xen | 1 Xen | 2019-11-14 | 6.9 MEDIUM | 6.8 MEDIUM |
| An issue was discovered in Xen through 4.12.x allowing attackers to gain host OS privileges via DMA in a situation where an untrusted domain has access to a physical device. This occurs because passed through PCI devices may corrupt host memory after deassignment. When a PCI device is assigned to an untrusted domain, it is possible for that domain to program the device to DMA to an arbitrary address. The IOMMU is used to protect the host from malicious DMA by making sure that the device addresses can only target memory assigned to the guest. However, when the guest domain is torn down, or the device is deassigned, the device is assigned back to dom0, thus allowing any in-flight DMA to potentially target critical host data. An untrusted domain with access to a physical device can DMA into host memory, leading to privilege escalation. Only systems where guests are given direct access to physical devices capable of DMA (PCI pass-through) are vulnerable. Systems which do not use PCI pass-through are not vulnerable. | |||||
| CVE-2019-17350 | 1 Xen | 1 Xen | 2019-10-26 | 4.9 MEDIUM | 5.5 MEDIUM |
| An issue was discovered in Xen through 4.12.x allowing Arm domU attackers to cause a denial of service (infinite loop) involving a compare-and-exchange operation. | |||||
| CVE-2019-17349 | 1 Xen | 1 Xen | 2019-10-26 | 4.9 MEDIUM | 5.5 MEDIUM |
| An issue was discovered in Xen through 4.12.x allowing Arm domU attackers to cause a denial of service (infinite loop) involving a LoadExcl or StoreExcl operation. | |||||
| CVE-2019-17348 | 1 Xen | 1 Xen | 2019-10-25 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service because of an incompatibility between Process Context Identifiers (PCID) and shadow-pagetable switching. | |||||
| CVE-2018-15468 | 1 Xen | 1 Xen | 2019-10-03 | 4.9 MEDIUM | 6.0 MEDIUM |
| An issue was discovered in Xen through 4.11.x. The DEBUGCTL MSR contains several debugging features, some of which virtualise cleanly, but some do not. In particular, Branch Trace Store is not virtualised by the processor, and software has to be careful to configure it suitably not to lock up the core. As a result, it must only be available to fully trusted guests. Unfortunately, in the case that vPMU is disabled, all value checking was skipped, allowing the guest to choose any MSR_DEBUGCTL setting it likes. A malicious or buggy guest administrator (on Intel x86 HVM or PVH) can lock up the entire host, causing a Denial of Service. | |||||
| CVE-2017-10919 | 1 Xen | 1 Xen | 2019-10-03 | 5.0 MEDIUM | 6.5 MEDIUM |
| Xen through 4.8.x mishandles virtual interrupt injection, which allows guest OS users to cause a denial of service (hypervisor crash), aka XSA-223. | |||||
| CVE-2017-14431 | 1 Xen | 1 Xen | 2019-10-03 | 4.9 MEDIUM | 5.5 MEDIUM |
| Memory leak in Xen 3.3 through 4.8.x allows guest OS users to cause a denial of service (ARM or x86 AMD host OS memory consumption) by continually rebooting, because certain cleanup is skipped if no pass-through device was ever assigned, aka XSA-207. | |||||
| CVE-2017-15593 | 1 Xen | 1 Xen | 2019-10-03 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.9.x allowing x86 PV guest OS users to cause a denial of service (memory leak) because reference counts are mishandled. | |||||
| CVE-2017-17044 | 1 Xen | 1 Xen | 2019-10-03 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.9.x allowing HVM guest OS users to cause a denial of service (infinite loop and host OS hang) by leveraging the mishandling of Populate on Demand (PoD) errors. | |||||
| CVE-2018-19965 | 3 Citrix, Debian, Xen | 3 Xenserver, Debian Linux, Xen | 2019-10-03 | 4.7 MEDIUM | 5.6 MEDIUM |
| An issue was discovered in Xen through 4.11.x allowing 64-bit PV guest OS users to cause a denial of service (host OS crash) because #GP[0] can occur after a non-canonical address is passed to the TLB flushing code. NOTE: this issue exists because of an incorrect CVE-2017-5754 (aka Meltdown) mitigation. | |||||
| CVE-2018-10981 | 2 Debian, Xen | 2 Debian Linux, Xen | 2019-10-03 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.10.x allowing x86 HVM guest OS users to cause a denial of service (host OS infinite loop) in situations where a QEMU device model attempts to make invalid transitions between states of a request. | |||||
| CVE-2018-12891 | 2 Debian, Xen | 2 Debian Linux, Xen | 2019-10-03 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.10.x. Certain PV MMU operations may take a long time to process. For that reason Xen explicitly checks for the need to preempt the current vCPU at certain points. A few rarely taken code paths did bypass such checks. By suitably enforcing the conditions through its own page table contents, a malicious guest may cause such bypasses to be used for an unbounded number of iterations. A malicious or buggy PV guest may cause a Denial of Service (DoS) affecting the entire host. Specifically, it may prevent use of a physical CPU for an indeterminate period of time. All Xen versions from 3.4 onwards are vulnerable. Xen versions 3.3 and earlier are vulnerable to an even wider class of attacks, due to them lacking preemption checks altogether in the affected code paths. Only x86 systems are affected. ARM systems are not affected. Only multi-vCPU x86 PV guests can leverage the vulnerability. x86 HVM or PVH guests as well as x86 single-vCPU PV ones cannot leverage the vulnerability. | |||||
| CVE-2018-12893 | 2 Debian, Xen | 2 Debian Linux, Xen | 2019-10-03 | 2.1 LOW | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.10.x. One of the fixes in XSA-260 added some safety checks to help prevent Xen livelocking with debug exceptions. Unfortunately, due to an oversight, at least one of these safety checks can be triggered by a guest. A malicious PV guest can crash Xen, leading to a Denial of Service. All Xen systems which have applied the XSA-260 fix are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only x86 PV guests can exploit the vulnerability. x86 HVM and PVH guests cannot exploit the vulnerability. An attacker needs to be able to control hardware debugging facilities to exploit the vulnerability, but such permissions are typically available to unprivileged users. | |||||
| CVE-2015-8553 | 2 Redhat, Xen | 2 Enterprise Linux, Xen | 2019-08-13 | 2.1 LOW | 6.5 MEDIUM |
| Xen allows guest OS users to obtain sensitive information from uninitialized locations in host OS kernel memory by not enabling memory and I/O decoding control bits. NOTE: this vulnerability exists because of an incomplete fix for CVE-2015-0777. | |||||
| CVE-2018-19967 | 2 Debian, Xen | 2 Debian Linux, Xen | 2019-04-17 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.11.x on Intel x86 platforms allowing guest OS users to cause a denial of service (host OS hang) because Xen does not work around Intel's mishandling of certain HLE transactions associated with the KACQUIRE instruction prefix. | |||||
| CVE-2018-15469 | 2 Debian, Xen | 2 Debian Linux, Xen | 2019-03-08 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.11.x. ARM never properly implemented grant table v2, either in the hypervisor or in Linux. Unfortunately, an ARM guest can still request v2 grant tables; they will simply not be properly set up, resulting in subsequent grant-related hypercalls hitting BUG() checks. An unprivileged guest can cause a BUG() check in the hypervisor, resulting in a denial-of-service (crash). | |||||
| CVE-2018-15470 | 1 Xen | 1 Xen | 2018-11-13 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.11.x. The logic in oxenstored for handling writes depended on the order of evaluation of expressions making up a tuple. As indicated in section 7.7.3 "Operations on data structures" of the OCaml manual, the order of evaluation of subexpressions is not specified. In practice, different implementations behave differently. Thus, oxenstored may not enforce the configured quota-maxentity. This allows a malicious or buggy guest to write as many xenstore entries as it wishes, causing unbounded memory usage in oxenstored. This can lead to a system-wide DoS. | |||||
| CVE-2018-7540 | 2 Debian, Xen | 2 Debian Linux, Xen | 2018-11-13 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.10.x allowing x86 PV guest OS users to cause a denial of service (host OS CPU hang) via non-preemptable L3/L4 pagetable freeing. | |||||
| CVE-2018-5244 | 1 Xen | 1 Xen | 2018-10-31 | 4.9 MEDIUM | 6.5 MEDIUM |
| In Xen 4.10, new infrastructure was introduced as part of an overhaul to how MSR emulation happens for guests. Unfortunately, one tracking structure isn't freed when a vcpu is destroyed. This allows guest OS administrators to cause a denial of service (host OS memory consumption) by rebooting many times. | |||||
| CVE-2018-7542 | 2 Debian, Xen | 2 Debian Linux, Xen | 2018-10-31 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen 4.8.x through 4.10.x allowing x86 PVH guest OS users to cause a denial of service (NULL pointer dereference and hypervisor crash) by leveraging the mishandling of configurations that lack a Local APIC. | |||||