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

Last updated 24 July 2024

Xen, possibly before 4.0.2, allows local 64-bit PV guests to cause a denial of service (host crash) by specifying user mode execution without user-mode pagetables.

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 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 (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.

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.

The outs instruction emulation in Xen 3.1.x, 4.2.x, 4.3.x, and earlier, when using FS: or GS: segment override, uses an uninitialized variable as a segment base, which allows local 64-bit PV guests to obtain sensitive information (hypervisor stack content) via unspecified vectors related to stale data in a segment register.

The fbld instruction emulation in Xen 3.3.x through 4.3.x does not use the correct variable for the source effective address, which allows local HVM guests to obtain hypervisor stack information by reading the values used by the instruction.

Xen 4.3.x and earlier does not properly handle certain errors, which allows local HVM guests to obtain hypervisor stack memory via a (1) port or (2) memory mapped I/O write or (3) other unspecified operations related to addresses without associated memory.

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).

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.

Xen 4.2.x, 4.1.x, and earlier, when the hypervisor is running "under memory pressure" and the Xen Security Module (XSM) is enabled, uses the wrong ordering of operations when extending the per-domain event channel tracking table, which causes a use-after-free and allows local guest kernels to inject arbitrary events and gain privileges via unspecified vectors.

Xen 3.1 through 4.x, when running 64-bit hosts on Intel CPUs, does not clear the NT flag when using an IRET after a SYSENTER instruction, which allows PV guest users to cause a denial of service (hypervisor crash) by triggering a #GP fault, which is not properly handled by another IRET instruction.

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 compatibility mode hypercall argument translation in Xen 3.3.x through 4.4.x, when running on a 64-bit hypervisor, allows local 32-bit HVM guests to cause a denial of service (host crash) via vectors involving altering the high halves of registers while in 64-bit mode.

arch/x86/x86emulate/x86emulate.c in Xen 3.2.1 through 4.4.x does not properly check privileges, which allows local HVM guest users to gain privileges or cause a denial of service (crash) via a crafted (1) CALL, (2) JMP, (3) RETF, (4) LCALL, (5) LJMP, or (6) LRET far branch instruction.

The x86emulate function in arch/x86/x86emulate/x86emulate.c in Xen 3.3.x through 4.4.x does not check the supervisor mode permissions for instructions that generate software interrupts, which allows local HVM guest users to cause a denial of service (guest crash) 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 memoryexchange function in common/memory.c in Xen 3.2.x through 4.6.x does not properly release locks, which might allow guest OS administrators to cause a denial of service (deadlock or host crash) via unspecified vectors, related to XENMEMexchange error handling.

The memoryexchange function in common/memory.c in Xen 3.2.x through 4.6.x does not properly hand back pages to a domain, which might allow guest OS administrators to cause a denial of service (host crash) via unspecified vectors related to domain teardown.

Xen 3.2.x through 4.6.x does not limit the number of printk console messages when logging certain pmu and profiling hypercalls, which allows local guests to cause a denial of service via a sequence of crafted (1) HYPERCALLxenoprofop hypercalls, which are not properly handled in the doxenoprofop function in common/xenoprof.c, or (2) HYPERVISORxenpmuop hypercalls, which are not properly handled in the doxenpmuop function in arch/x86/cpu/vpmu.c.

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.

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.

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 emulation routines for unspecified X86 devices in Xen 3.2.x through 4.5.x does not properly initialize data, which allow local HVM guest users to obtain sensitive information via vectors involving an unsupported access size.

The HYPERVISORxenversion hypercall in Xen 3.2.x through 4.5.x does not properly initialize data structures, which allows local guest users to obtain sensitive information via unspecified vectors.

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.