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.
An issue was discovered in Xen 4.5.x through 4.9.x. The function gnttabcacheflush handles GNTTABOPcacheflush grant table operations. It checks to see if the calling domain is the owner of the page that is to be operated on. If it is not, the owner's grant table is checked to see if a grant mapping to the calling domain exists for the page in question. However, the function does not check to see if the owning domain actually has a grant table or not. Some special domains, such as DOMIDXEN, DOMIDIO and DOMIDCOW are created without grant tables. Hence, if gnttabcacheflush operates on a page owned by these special domains, it will attempt to dereference a NULL pointer in the domain struct.
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.
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.
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.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.
The vCPU context-switch implementation in Xen through 4.8.x improperly interacts with the Memory Protection Extensions (MPX) and Protection Key (PKU) features, which makes it easier for guest OS users to defeat ASLR and other protection mechanisms, aka XSA-220.
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.
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.
Xen through 4.8.x mishandles page transfer, which allows guest OS users to obtain privileged host OS access, aka XSA-217.
The grant-table feature in Xen through 4.8.x does not ensure sufficient type counts for a GNTMAPdevicemap and GNTMAPhostmap mapping, which allows guest OS users to cause a denial of service (count mismanagement and memory corruption) or obtain privileged host OS access, aka XSA-224 bug 2.
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 through 4.8.x mishandles virtual interrupt injection, which allows guest OS users to cause a denial of service (hypervisor crash), aka XSA-223.
The grant-table feature in Xen through 4.8.x mishandles a GNTMAPdevicemap and GNTMAPhostmap mapping, when followed by only a GNTMAPhostmap unmapping, which allows guest OS users to cause a denial of service (count mismanagement and memory corruption) or obtain privileged host OS access, aka XSA-224 bug 1.
Xen through 4.8.x does not validate memory allocations during certain P2M operations, which allows guest OS users to obtain privileged host OS access, aka XSA-222.
Xen through 4.8.x mishandles the "contains segment descriptors" property during GNTTABOPtransfer (aka guest transfer) operations, which might allow PV guest OS users to execute arbitrary code on the host OS, aka XSA-214.
Xen through 4.8.x on 64-bit platforms mishandles page tables after an IRET hypercall, which might allow PV guest OS users to execute arbitrary code on the host OS, aka XSA-213.