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.
The PV superpage functionality in arch/x86/mm.c in Xen 3.4.0, 3.4.1, and 4.1.x through 4.6.x allows local PV guests to obtain sensitive information, cause a denial of service, gain privileges, or have unspecified other impact via a crafted page identifier (MFN) to the (1) MMUEXTMARKSUPER or (2) MMUEXTUNMARKSUPER sub-op in the HYPERVISORmmuextop hypercall or (3) unknown vectors related to page table updates.
The hvmmsrreadintercept function in arch/x86/hvm/hvm.c in Xen 4.1 through 4.4.x uses an improper MSR range for x2APIC emulation, which allows local HVM guests to cause a denial of service (host crash) or read data from the hypervisor or other guests via unspecified vectors.
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.
The libxl toolstack library in Xen 4.1.x through 4.6.x does not properly release mappings of files used as kernels and initial ramdisks when managing multiple domains in the same process, which allows attackers to cause a denial of service (memory and disk consumption) by starting domains.
An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service or gain privileges because a guest can manipulate its virtualised %cr4 in a way that is incompatible with Linux (and possibly other guest kernels).
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 dotmemop function in the Transcendent Memory (TMEM) in Xen 4.0, 4.1, and 4.2 allow local guest OS users to cause a denial of service (host crash) and possibly have other unspecified impacts via unspecified vectors related to "broken locking checks" in an "error path." NOTE: this issue was originally published as part of CVE-2012-3497, which was too general; CVE-2012-3497 has been SPLIT into this ID and others.
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.
The dotmemdestroypool function in the Transcendent Memory (TMEM) in Xen 4.0, 4.1, and 4.2 does not properly validate pool ids, which allows local guest OS users to cause a denial of service (memory corruption and host crash) or execute arbitrary code via unspecified vectors. NOTE: this issue was originally published as part of CVE-2012-3497, which was too general; CVE-2012-3497 has been SPLIT into this ID and others.
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.
Stack-based buffer overflow in the xl command line utility in Xen 4.1.x through 4.5.x allows local guest administrators to gain privileges via a long configuration argument.
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 paginginvlpg function in include/asm-x86/paging.h in Xen 3.3.x through 4.6.x, when using shadow mode paging or nested virtualization is enabled, allows local HVM guest users to cause a denial of service (host crash) via a non-canonical guest address in an INVVPID instruction, which triggers a hypervisor bug check.
Xen 4.2.x, 4.1.x, and 4.0, when using Intel VT-d for PCI passthrough, does not properly configure VT-d when supporting a device that is behind a legacy PCI Bridge, which allows local guests to cause a denial of service to other guests by injecting an interrupt.
Race condition in HVMOPtrackdirtyvram in Xen 4.0.0 through 4.4.x does not ensure possession of the guarding lock for dirty video RAM tracking, which allows certain local guest domains to cause a denial of service via unspecified vectors.
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 Ocaml xenstored implementation (oxenstored) in Xen 4.1.x, 4.2.x, and 4.3.x allows local guest domains to cause a denial of service (domain shutdown) via a large message reply.
Xen before 4.1.x, 4.2.x, and 4.3.x does not take the pagealloclock and granttable.lock in the same order, which allows local guest administrators with access to multiple vcpus to cause a denial of service (host deadlock) 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.