The PV pagetable code in arch/x86/mm.c in Xen 4.7.x and earlier allows local 32-bit PV guest OS administrators to gain host OS privileges by leveraging fast-paths for updating pagetable entries.

Xen 3.3.x through 4.5.x does not properly restrict access to PCI MSI mask bits, which allows local x86 HVM guest users to cause a denial of service (unexpected interrupt and host crash) via unspecified vectors.

Buffer overflow in the Python bindings for the xcvcpusetaffinity call in Xen 4.0.x, 4.1.x, and 4.2.x allows local administrators with permissions to configure VCPU affinity to cause a denial of service (memory corruption and xend toolstack crash) and possibly gain privileges via a crafted cpumap.

The libxenlight (libxl) toolstack library in Xen 4.0.x, 4.1.x, and 4.2.x uses weak permissions for xenstore keys for paravirtualised and emulated serial console devices, which allows local guest administrators to modify the xenstore value via unspecified vectors.

On Intel CPUs sysret to non-canonical address causes a fault on the sysret instruction itself after the stack pointer is set to guest value but before the CPL is changed. Systems running on AMD CPUs are not vulnerable to this issue as sysret on AMD CPUs does not generate a fault before the CPL change.

On Xen, a privileged user on a 64 bit PV guest kernel running on a 64 bit hypervisor could use this flaw to escalate privileges to that of the host. Depending on the particular guest kernel it is also possible that non-privileged guest users could also elevate their privileges to that of the host.

For Red Hat Enterprise Linux guests, only privileged guest users can exploit this issue. HVM guests and 32-bit PV guests cannot be used to exploit this issue.

Acknowledgements:

Red Hat would like to thank the Xen project for reporting this issue. Upstream acknowledges Rafal Wojtczuk as the original reporter.

The x86 emulator in Xen 3.2.x through 4.5.x does not properly ignore segment overrides for instructions with register operands, which allows local guest users to obtain sensitive information, cause a denial of service (memory corruption), or possibly execute arbitrary code via unspecified vectors.

The modl2entry function in arch/x86/mm.c in Xen 3.4 through 4.6.x does not properly validate level 2 page table entries, which allows local PV guest administrators to gain privileges via a crafted superpage mapping.

The dommuupdate function in arch/x86/mm.c in Xen 3.2.x through 4.4.x does not properly manage page references, which allows remote domains to cause a denial of service by leveraging control over an HVM guest and a crafted MMUMACHPHYSUPDATE.

The XENMEMexchange handler in Xen 4.2 and earlier does not properly check the memory address, which allows local PV guest OS administrators to cause a denial of service (crash) or possibly gain privileges via unspecified vectors that overwrite memory in the hypervisor reserved range.

Xen 4.0.x and 4.1.x incorrectly releases a grant reference when releasing a non-v1, non-transitive grant, which allows local guest administrators to cause a denial of service (host crash), obtain sensitive information, or possibly have other impacts via unspecified vectors.

The xenlight library (libxl) in Xen 4.0.x through 4.2.x, when IOMMU is disabled, provides access to a busmastering-capable PCI passthrough device before the IOMMU setup is complete, which allows local HVM guest domains to gain privileges or cause a denial of service via a DMA instruction.

The x86emulate function in arch/x86/x86emulate/x86emulate.c in Xen 4.4.x and earlier does not properly check supervisor mode permissions, which allows local HVM users to cause a denial of service (guest crash) or gain guest kernel mode privileges via vectors involving an (1) HLT, (2) LGDT, (3) LIDT, or (4) LMSW instruction.

The vmxsetucmode function in Xen 3.3 through 4.3, when disabling caches, allows local HVM guests with access to memory mapped I/O regions to cause a denial of service (CPU consumption and possibly hypervisor or guest kernel panic) via a crafted GFN range.

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.

The dommuupdate function in arch/x86/mm.c in Xen 4.x through 4.4.x does not properly restrict updates to only PV page tables, which allows remote PV guests to cause a denial of service (NULL pointer dereference) by leveraging hardware emulation services for HVM guests using Hardware Assisted Paging (HAP).

Xen 4.0.x, 4.1.x, and 4.2.x does not properly restrict the contents of a XRSTOR, which allows local PV guest users to cause a denial of service (unhandled exception and hypervisor crash) via unspecified vectors.

The XENDOMCTLgetmemlist hypercall in Xen 3.4.x through 4.3.x (possibly 4.3.1) does not always obtain the pagealloclock and mmrwlock in the same order, which allows local guest administrators to cause a denial of service (host deadlock).

Xen 3.0.3 through 4.1.x (possibly 4.1.6.1), 4.2.x (possibly 4.2.3), and 4.3.x (possibly 4.3.1) does not properly prevent access to hypercalls, which allows local guest users to gain privileges via a crafted application running in ring 1 or 2.

Xen 3.3.x through 4.5.x enables logging for PCI MSI-X pass-through error messages, which allows local x86 HVM guests to cause a denial of service (host disk consumption) via certain invalid operations.

The compatiret function in Xen 3.1 through 4.5 iterates the wrong way through a loop, which allows local 32-bit PV guest administrators to cause a denial of service (large loop and system hang) via a hypercalliret call with EFLAGS.VM set.

Xen 3.3.x through 4.5.x does not properly restrict write access to the host MSI message data field, which allows local x86 HVM guest administrators to cause a denial of service (host interrupt handling confusion) via vectors related to qemu and accessing spanning multiple fields.

Multiple memory leaks in Xen 4.0 through 4.6.x allow local guest administrators or domains with certain permission to cause a denial of service (memory consumption) via a large number of "teardowns" of domains with the vcpu pointer array allocated using the (1) XENDOMCTLmaxvcpus hypercall or the xenoprofile state vcpu pointer array allocated using the (2) XENOPROFgetbuffer or (3) XENOPROFsetpassive hypercall.

ISSUE DESCRIPTION =================

Guests are currently permitted to modify all of the (writable) bits in the PCI command register of devices passed through to them. This in particular allows them to disable memory and I/O decoding on the device unless the device is an SR-IOV virtual function, in which case subsequent accesses to the respective MMIO or I/O port ranges would - - on PCI Express devices - lead to Unsupported Request responses. The treatmeant of such errors is platform specific.

IMPACT ======

In the event that the platform surfaces aforementioned UR responses as Non-Maskable Interrupts, and either the OS is configured to treat NMIs as fatal or (e.g. via ACPI's APEI) the platform tells the OS to treat these errors as fatal, the host would crash, leading to a Denial of Service.

VULNERABLE SYSTEMS ==================

Xen versions 3.3 and onwards are vulnerable due to supporting PCI pass-through. Upstream Linux versions 3.1 and onwards are vulnerable due to supporting PCI backend functionality. Other Linux versions as well as other OS versions may be vulnerable too.

Any domain which is given access to a non-SR-IOV virtual function PCI Express device can take advantage of this vulnerability.

MITIGATION ==========

This issue can be avoided by not assigning PCI Express devices other than SR-IOV virtual functions to untrusted guests.

RESOLUTION ==========

Applying the attached patch resolves this issue for upstream Linux.

xsa120.patch Linux 3.19

$ sha256sum xsa120.patch 5167215293d4a8a05f090fca5b20eb5878213a0158a0e7a12c245553db81a855 xsa120.patch

The guestphysmapmarkpopulateondemand function in Xen 4.2 and earlier does not properly unlock the subject GFNs when checking if they are in use, which allows local guest HVM administrators to cause a denial of service (hang) via unspecified vectors.

The (1) XENMEMdecreasereservation, (2) XENMEMpopulatephysmap, and (3) XENMEMexchange hypercalls in Xen 4.2 and earlier allow local guest administrators to cause a denial of service (long loop and hang) via a crafted extentorder value.

Multiple HVM control operations in Xen 3.4 through 4.2 allow local HVM guest OS administrators to cause a denial of service (physical CPU consumption) via a large input.

Stack-based buffer overflow in the dirty video RAM tracking functionality in Xen 3.4 through 4.1 allows local HVM guest OS administrators to cause a denial of service (crash) via a large bitmap image.

Xen 4.x, when downgrading the grant table version, does not properly remove the status page from the tracking list when freeing the page, which allows local guest OS administrators to cause a denial of service (hypervisor crash) via unspecified vectors.

The Intel VT-d Interrupt Remapping engine in Xen 3.3.x through 4.3.x allows local guests to cause a denial of service (kernel panic) via a malformed Message Signaled Interrupt (MSI) from a PCI device that is bus mastering capable that triggers a System Error Reporting (SERR) Non-Maskable Interrupt (NMI).

Xen 4.0.2 through 4.0.4, 4.1.x, and 4.2.x allows local PV guest users to cause a denial of service (hypervisor crash) via certain bit combinations to the XSETBV instruction.