Filtered by vendor Xen
Subscribe
Total
469 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2019-17340 | 2 Debian, Xen | 2 Debian Linux, Xen | 2022-03-31 | 6.1 MEDIUM | 8.8 HIGH |
| An issue was discovered in Xen through 4.11.x allowing x86 guest OS users to cause a denial of service or gain privileges because grant-table transfer requests are mishandled. | |||||
| CVE-2020-29487 | 1 Xen | 1 Xapi | 2021-12-10 | 7.8 HIGH | 7.5 HIGH |
| An issue was discovered in Xen XAPI before 2020-12-15. Certain xenstore keys provide feedback from the guest, and are therefore watched by toolstack. Specifically, keys are watched by xenopsd, and data are forwarded via RPC through message-switch to xapi. The watching logic in xenopsd sends one RPC update containing all data, any time any single xenstore key is updated, and therefore has O(N^2) time complexity. Furthermore, message-switch retains recent (currently 128) RPC messages for diagnostic purposes, yielding O(M*N) space complexity. The quantity of memory a single guest can monopolise is bounded by xenstored quota, but the quota is fairly large. It is believed to be in excess of 1G per malicious guest. In practice, this manifests as a host denial of service, either through message-switch thrashing against swap, or OOMing entirely, depending on dom0's configuration. (There are no quotas in xenopsd to limit the quantity of keys that result in RPC traffic.) A buggy or malicious guest can cause unreasonable memory usage in dom0, resulting in a host denial of service. All versions of XAPI are vulnerable. Systems that are not using the XAPI toolstack are not vulnerable. | |||||
| 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-2021-28692 | 1 Xen | 1 Xen | 2021-07-12 | 5.6 MEDIUM | 7.1 HIGH |
| inappropriate x86 IOMMU timeout detection / handling IOMMUs process commands issued to them in parallel with the operation of the CPU(s) issuing such commands. In the current implementation in Xen, asynchronous notification of the completion of such commands is not used. Instead, the issuing CPU spin-waits for the completion of the most recently issued command(s). Some of these waiting loops try to apply a timeout to fail overly-slow commands. The course of action upon a perceived timeout actually being detected is inappropriate: - on Intel hardware guests which did not originally cause the timeout may be marked as crashed, - on AMD hardware higher layer callers would not be notified of the issue, making them continue as if the IOMMU operation succeeded. | |||||
| CVE-2007-1320 | 5 Debian, Fedoraproject, Opensuse and 2 more | 6 Debian Linux, Fedora, Fedora Core and 3 more | 2020-12-15 | 7.2 HIGH | N/A |
| Multiple heap-based buffer overflows in the cirrus_invalidate_region function in the Cirrus VGA extension in QEMU 0.8.2, as used in Xen and possibly other products, might allow local users to execute arbitrary code via unspecified vectors related to "attempting to mark non-existent regions as dirty," aka the "bitblt" heap overflow. | |||||
| CVE-2007-1321 | 4 Debian, Fedoraproject, Qemu and 1 more | 5 Debian Linux, Fedora, Fedora Core and 2 more | 2020-12-15 | 7.2 HIGH | N/A |
| Integer signedness error in the NE2000 emulator in QEMU 0.8.2, as used in Xen and possibly other products, allows local users to trigger a heap-based buffer overflow via certain register values that bypass sanity checks, aka QEMU NE2000 "receive" integer signedness error. NOTE: this identifier was inadvertently used by some sources to cover multiple issues that were labeled "NE2000 network driver and the socket code," but separate identifiers have been created for the individual vulnerabilities since there are sometimes different fixes; see CVE-2007-5729 and CVE-2007-5730. | |||||
| CVE-2007-5730 | 3 Debian, Qemu, Xen | 3 Debian Linux, Qemu, Xen | 2020-12-15 | 7.2 HIGH | N/A |
| Heap-based buffer overflow in QEMU 0.8.2, as used in Xen and possibly other products, allows local users to execute arbitrary code via crafted data in the "net socket listen" option, aka QEMU "net socket" heap overflow. NOTE: some sources have used CVE-2007-1321 to refer to this issue as part of "NE2000 network driver and the socket code," but this is the correct identifier for the individual net socket listen vulnerability. | |||||
| CVE-2011-2519 | 2 Redhat, Xen | 4 Enterprise Linux Desktop, Enterprise Linux Server, Enterprise Linux Workstation and 1 more | 2020-12-08 | 5.5 MEDIUM | N/A |
| Xen in the Linux kernel, when running a guest on a host without hardware assisted paging (HAP), allows guest users to cause a denial of service (invalid pointer dereference and hypervisor crash) via the SAHF instruction. | |||||
| CVE-2012-0217 | 8 Citrix, Freebsd, Illumos and 5 more | 11 Xenserver, Freebsd, Illumos and 8 more | 2020-09-28 | 7.2 HIGH | N/A |
| The x86-64 kernel system-call functionality in Xen 4.1.2 and earlier, as used in Citrix XenServer 6.0.2 and earlier and other products; Oracle Solaris 11 and earlier; illumos before r13724; Joyent SmartOS before 20120614T184600Z; FreeBSD before 9.0-RELEASE-p3; NetBSD 6.0 Beta and earlier; Microsoft Windows Server 2008 R2 and R2 SP1 and Windows 7 Gold and SP1; and possibly other operating systems, when running on an Intel processor, incorrectly uses the sysret path in cases where a certain address is not a canonical address, which allows local users to gain privileges via a crafted application. NOTE: because this issue is due to incorrect use of the Intel specification, it should have been split into separate identifiers; however, there was some value in preserving the original mapping of the multi-codebase coordinated-disclosure effort to a single identifier. | |||||
| 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-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-2017-12135 | 3 Citrix, Debian, Xen | 3 Xenserver, Debian Linux, Xen | 2020-04-14 | 4.6 MEDIUM | 8.8 HIGH |
| Xen allows local OS guest users to cause a denial of service (crash) or possibly obtain sensitive information or gain privileges via vectors involving transitive grants. | |||||
| CVE-2017-15590 | 1 Xen | 1 Xen | 2019-10-03 | 4.6 MEDIUM | 8.8 HIGH |
| An issue was discovered in Xen through 4.9.x allowing x86 guest OS users to cause a denial of service (hypervisor crash) or possibly gain privileges because MSI mapping was mishandled. | |||||
| CVE-2017-12134 | 2 Citrix, Xen | 2 Xenserver, Xen | 2019-10-03 | 7.2 HIGH | 8.8 HIGH |
| The xen_biovec_phys_mergeable function in drivers/xen/biomerge.c in Xen might allow local OS guest users to corrupt block device data streams and consequently obtain sensitive memory information, cause a denial of service, or gain host OS privileges by leveraging incorrect block IO merge-ability calculation. | |||||
| CVE-2017-14319 | 1 Xen | 1 Xen | 2019-10-03 | 7.2 HIGH | 8.8 HIGH |
| A grant unmapping issue was discovered in Xen through 4.9.x. When removing or replacing a grant mapping, the x86 PV specific path needs to make sure page table entries remain in sync with other accounting done. Although the identity of the page frame was validated correctly, neither the presence of the mapping nor page writability were taken into account. | |||||
| CVE-2017-15592 | 1 Xen | 1 Xen | 2019-10-03 | 7.2 HIGH | 8.8 HIGH |
| An issue was discovered in Xen through 4.9.x allowing x86 HVM guest OS users to cause a denial of service (hypervisor crash) or possibly gain privileges because self-linear shadow mappings are mishandled for translated guests. | |||||
| CVE-2017-8904 | 1 Xen | 1 Xen | 2019-10-03 | 6.8 MEDIUM | 8.8 HIGH |
| Xen through 4.8.x mishandles the "contains segment descriptors" property during GNTTABOP_transfer (aka guest transfer) operations, which might allow PV guest OS users to execute arbitrary code on the host OS, aka XSA-214. | |||||
| CVE-2018-8897 | 8 Apple, Canonical, Citrix and 5 more | 11 Mac Os X, Ubuntu Linux, Xenserver and 8 more | 2019-10-03 | 7.2 HIGH | 7.8 HIGH |
| A statement in the System Programming Guide of the Intel 64 and IA-32 Architectures Software Developer's Manual (SDM) was mishandled in the development of some or all operating-system kernels, resulting in unexpected behavior for #DB exceptions that are deferred by MOV SS or POP SS, as demonstrated by (for example) privilege escalation in Windows, macOS, some Xen configurations, or FreeBSD, or a Linux kernel crash. The MOV to SS and POP SS instructions inhibit interrupts (including NMIs), data breakpoints, and single step trap exceptions until the instruction boundary following the next instruction (SDM Vol. 3A; section 6.8.3). (The inhibited data breakpoints are those on memory accessed by the MOV to SS or POP to SS instruction itself.) Note that debug exceptions are not inhibited by the interrupt enable (EFLAGS.IF) system flag (SDM Vol. 3A; section 2.3). If the instruction following the MOV to SS or POP to SS instruction is an instruction like SYSCALL, SYSENTER, INT 3, etc. that transfers control to the operating system at CPL < 3, the debug exception is delivered after the transfer to CPL < 3 is complete. OS kernels may not expect this order of events and may therefore experience unexpected behavior when it occurs. | |||||