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.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.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 ESREL2.EA bit set.

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 an incorrect choice for software interrupt delivery.

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 4.7 allows local guest OS users to obtain sensitive host information by loading a 32-bit ELF symbol table.

VMFUNC emulation in Xen 4.6.x through 4.8.x on x86 systems using AMD virtualization extensions (aka SVM) allows local HVM guest OS users to cause a denial of service (hypervisor crash) by leveraging a missing NULL pointer check.

Xen 4.0.x through 4.7.x mishandle x86 task switches to VM86 mode, which allows local 32-bit x86 HVM guest OS users to gain privileges or cause a denial of service (guest OS crash) by leveraging a guest operating system that uses hardware task switching and allows a new task to start in VM86 mode.

The x86 segment base write emulation functionality in Xen 4.4.x through 4.7.x allows local x86 PV guest OS administrators to cause a denial of service (host crash) by leveraging lack of canonical address checks.

An issue was discovered in Xen 4.5.x through 4.9.x allowing attackers (who control a stub domain kernel or tool stack) to cause a denial of service (host OS crash) because of a missing comparison (of range start to range end) within the DMOP map/unmap implementation.

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.

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

The grant table code in Xen has a bespoke semi-lockfree allocator for recording grant mappings ("maptrack" entries). This allocator has a race which allows the free list to be corrupted.

Specifically: the code for removing an entry from the free list, prior to use, assumes (without locking) that if inspecting head item shows that it is not the tail, it will continue to not be the tail of the list if it is later found to be still the head and removed with cmpxchg. But the entry might have been removed and replaced, with the result that it might be the tail by then. (The invariants for the semi-lockfree data structure were never formally documented.)

Additionally, a stolen entry is put on the free list with an incorrect link field, which will very likely corrupt the list.

IMPACT ======

A malicious guest administrator can crash the host, and can probably escalate their privilege to that of the host.

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

Xen 4.6 and later are vulnerable.

Xen 4.5 and earlier are not vulnerable.

MITIGATION ==========

There is no mitigation for this vulnerability.

External References:

http://xenbits.xen.org/xsa/advisory-228.html