| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| arch/x86/mm.c in Xen allows local PV guest OS users to gain host OS privileges via vectors related to map_grant_ref. |
| 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. |
| Xen maintains the _GTF_{read,writ}ing bits as appropriate, to inform the guest that a grant is in use. A guest is expected not to modify the grant details while it is in use, whereas the guest is free to modify/reuse the grant entry when it is not in use. Under some circumstances, Xen will clear the status bits too early, incorrectly informing the guest that the grant is no longer in use. A guest may prematurely believe that a granted frame is safely private again, and reuse it in a way which contains sensitive information, while the domain on the far end of the grant is still using the grant. Xen 4.9, 4.8, 4.7, 4.6, and 4.5 are affected. |
| 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. |
| 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. |
| Xen through 4.8.x does not validate a vCPU array index upon the sending of an SGI, which allows guest OS users to cause a denial of service (hypervisor crash), aka XSA-225. |
| An issue was discovered in Xen through 4.9.x allowing x86 SVM PV guest OS users to cause a denial of service (hypervisor crash) or gain privileges because IDT settings are mishandled during CPU hotplugging. |
| Xen through 4.7.x allows local ARM guest OS users to cause a denial of service (host panic) by sending an asynchronous abort. |
| 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. |
| Xen PV guest before Xen 4.3 checked access permissions to MMIO ranges only after accessing them, allowing host PCI device space memory reads, leading to information disclosure. This is an error in the get_user function. NOTE: the upstream Xen Project considers versions before 4.5.x to be EOL. |
| An issue (known as XSA-212) was discovered in Xen, with fixes available for 4.8.x, 4.7.x, 4.6.x, 4.5.x, and 4.4.x. The earlier XSA-29 fix introduced an insufficient check on XENMEM_exchange input, allowing the caller to drive hypervisor memory accesses outside of the guest provided input/output arrays. |
| Xen through 4.8.x does not validate the port numbers of polled event channel ports, which allows guest OS users to cause a denial of service (NULL pointer dereference and host OS crash) or possibly obtain sensitive information, aka XSA-221. |
| 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. |
| 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. |
| The grant-table feature in Xen through 4.8.x mishandles MMIO region grant references, which allows guest OS users to cause a denial of service (loss of grant trackability), aka XSA-224 bug 3. |
| An issue was discovered in Xen through 4.9.x. Grant copying code made an implication that any grant pin would be accompanied by a suitable page reference. Other portions of code, however, did not match up with that assumption. When such a grant copy operation is being done on a grant of a dying domain, the assumption turns out wrong. A malicious guest administrator can cause hypervisor memory corruption, most likely resulting in host crash and a Denial of Service. Privilege escalation and information leaks cannot be ruled out. |
| 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 PV guest OS users to cause a denial of service (host OS crash) or gain host OS privileges in shadow mode by mapping a certain auxiliary page. |
| 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. |
| 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. |
