| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Xen through 4.6.x on 64-bit platforms mishandles a failsafe callback, which might allow PV guest OS users to execute arbitrary code on the host OS, aka XSA-215. |
| 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. |
| An issue was discovered in Xen through 4.9.x allowing guest OS users to cause a denial of service (host OS crash) or gain host OS privileges by leveraging an incorrect mask for reference-count overflow checking in shadow mode. |
| Xen through 4.7.x allows local ARM guest OS users to cause a denial of service (host crash) via vectors involving a (1) data or (2) prefetch abort with the ESR_EL2.EA bit set. |
| Xen through 4.7.x allows local ARM guest OS users to cause a denial of service (host crash) via vectors involving an asynchronous abort while at EL2. |
| Xen through 4.7.x allows local ARM guest OS users to cause a denial of service (host panic) by sending an asynchronous abort. |
| 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. |
| An issue was discovered in Xen through 4.9.x allowing guest OS users to cause a denial of service (host OS crash) or gain host OS privileges by leveraging incorrect error handling for reference counting in shadow mode. |
| The grant-table feature in Xen through 4.8.x provides false mapping information in certain cases of concurrent unmap calls, which allows backend attackers to obtain sensitive information or gain privileges, aka XSA-218 bug 1. |
| Xen through 4.7.x allows local ARM guest OS users to cause a denial of service (host crash) via vectors involving an asynchronous abort while at HYP. |
| Xen through 4.8.x mishandles page transfer, which allows guest OS users to obtain privileged host OS access, aka XSA-217. |
| An issue was discovered in Xen through 4.9.x allowing x86 HVM guest OS users to obtain sensitive information from the host OS (or an arbitrary guest OS) because intercepted I/O operations can cause a write of data from uninitialized hypervisor stack memory. |
| 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. |
| An issue was discovered in Xen through 4.9.x allowing PV guest OS users to cause a denial of service (host OS crash) if shadow mode and log-dirty mode are in place, because of an incorrect assertion related to M2P. |
| The grant-table feature in Xen through 4.8.x has a race condition leading to a double free, which allows guest OS users to cause a denial of service (memory consumption), or possibly obtain sensitive information or gain privileges, aka XSA-218 bug 2. |
| An issue was discovered in Xen through 4.9.x on the ARM platform allowing guest OS users to obtain sensitive information from DRAM after a reboot, because disjoint blocks, and physical addresses that do not start at zero, are mishandled. |
| Xen through 4.8.x allows local x86 PV guest OS kernel administrators to cause a denial of service (host hang or crash) by modifying the instruction stream asynchronously while performing certain kernel operations. |
| Xen 4.5.x through 4.7.x on AMD systems without the NRip feature, when emulating instructions that generate software interrupts, allows local HVM guest OS users to cause a denial of service (guest crash) by leveraging IDT entry miscalculation. |
| The shadow-paging feature in Xen through 4.8.x mismanages page references and consequently introduces a race condition, which allows guest OS users to obtain Xen privileges, aka XSA-219. |
| An issue was discovered in Xen 4.4.x through 4.9.x allowing ARM guest OS users to cause a denial of service (prevent physical CPU usage) because of lock mishandling upon detection of an add-to-physmap error. |
