An issue was discovered in Xen through 4.9.x. Grant copying code made an implication that any grant pin would be accompanied by a suitable page reference. Other portions of code, however, did not match up with that assumption. When such a grant copy operation is being done on a grant of a dying domain, the assumption turns out wrong. A malicious guest administrator can cause hypervisor memory corruption, most likely resulting in host crash and a Denial of Service. Privilege escalation and information leaks cannot be ruled out.

Shadow mode tracing code uses a set of per-CPU variables to avoid cumbersome parameter passing. Some of these variables are written to with guest controlled data, of guest controllable size. That size can be larger than the variable, and bounding of the writes was missing.

An issue was discovered in Xen through 4.10.x allowing guest OS users to cause a denial of service (hypervisor crash) or gain privileges by triggering a grant-table transition from v2 to v1.

arch/x86/mm.c in Xen allows local PV guest OS users to gain host OS privileges via vectors related to mapgrantref.

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

Code to handle copy operations on transitive grants has built in retry logic, involving a function reinvoking itself with unchanged parameters. Such use assumes that the compiler would also translate this to a so called "tail call" when generating machine code. Empirically, this is not commonly the case, allowing for theoretically unbounded nesting of such function calls.

IMPACT ======

A malicious or buggy guest may be able to crash Xen. Privilege escalation and information leaks cannot be ruled out.

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

All versions of Xen are vulnerable.

MITIGATION ==========

There is no known mitigation.

External References:

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

An issue was discovered in Xen through 4.9.x allowing HVM guest OS users to gain privileges on the host OS, obtain sensitive information, or cause a denial of service (BUG and host OS crash) by leveraging the mishandling of Populate on Demand (PoD) Physical-to-Machine (P2M) errors.

An issue was discovered in Xen through 4.9.x allowing x86 guest OS users to cause a denial of service (hypervisor crash) or possibly gain privileges because MSI mapping was mishandled.

An issue was discovered in Xen through 4.9.x allowing x86 HVM guest OS users to cause a denial of service (hypervisor crash) or possibly gain privileges because self-linear shadow mappings are mishandled for translated guests.

An issue was discovered in Xen through 4.9.x allowing x86 SVM PV guest OS users to cause a denial of service (hypervisor crash) or gain privileges because IDT settings are mishandled during CPU hotplugging.

An issue was discovered in Xen through 4.9.x allowing x86 PV guest OS users to cause a denial of service (unbounded recursion, stack consumption, and hypervisor crash) or possibly gain privileges via crafted page-table stacking.

Xen, when running on a 64-bit hypervisor, allows local x86 guest OS users to modify arbitrary memory and consequently obtain sensitive information, cause a denial of service (host crash), or execute arbitrary code on the host by leveraging broken emulation of bit test instructions.

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

The block layer in Linux may choose to merge adjacent block IO requests. When Linux is running as a Xen guest, the default merging algorithm is replaced with a Xen-specific one. When Linux is running as an x86 PV guest, some BIO's are erroneously merged, corrupting the data stream to/from the block device.

This can result in incorrect access to an uncontrolled adjacent frame.

IMPACT ======

A buggy or malicious guest can cause Linux to read or write incorrect memory when processing a block stream. This could leak information from other guests in the system or from Xen itself, or be used to DoS or escalate privilege within the system.

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

All x86 Xen systems using pvops Linux in a backend role (either as dom0, or as a disk device driver domain) are affected. This includes upstream Linux versions 2.6.37 and later. Systems using the older classic-linux fork are not affected.

All PV x86 domains doing block IO on behalf of a guest, including dom0 and any PV driver domains, are vulnerable. (Any HVM driver domains running are not vulnerable.) This includes Xen vbd backends such as blkback, but also direct IO performed for the guest via eg qemu.

ARM systems are not affected.

The vulnerability is only exposed if the underlying block device has request merging enabled. See Mitigation.

The vulnerability is only exposed to configurations which use grant mapping as a transport mechanism for the block data. Configurations which use exclusively grant copy are not vulnerable.

MITIGATION ==========

Disable bio merges on all relevant underlying backend block devices. For example, echo 2 > /sys/block/nvme0n1/queue/nomerges

External References:

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

An issue was discovered in xenoprof in Xen through 4.13.x, allowing guest OS users (with active profiling) to obtain sensitive information about other guests, cause a denial of service, or possibly gain privileges. For guests for which "active" profiling was enabled by the administrator, the xenoprof code uses the standard Xen shared ring structure. Unfortunately, this code did not treat the guest as a potential adversary: it trusts the guest not to modify buffer size information or modify head / tail pointers in unexpected ways. This can crash the host (DoS). Privilege escalation cannot be ruled out.

Xenstore: Guests can crash xenstored Due to a bug in the fix of XSA-115 a malicious guest can cause xenstored to use a wrong pointer during node creation in an error path, resulting in a crash of xenstored or a memory corruption in xenstored causing further damage. Entering the error path can be controlled by the guest e.g. by exceeding the quota value of maximum nodes per domain.

The AdSanity plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the 'ajaxupload' function in versions up to, and including, 1.8.1. This makes it possible for authenticated attackers with Contributor+ level privileges to upload arbitrary files on the affected sites server which makes remote code execution possible.

The dophysdevop function in Xen 4.1.5, 4.1.6.1, 4.2.2 through 4.2.3, and 4.3.x does not properly restrict access to the (1) PHYSDEVOPpreparemsix and (2) PHYSDEVOPreleasemsix operations, which allows local PV guests to cause a denial of service (host or guest malfunction) or possibly gain privileges via unspecified vectors.

An issue (known as XSA-212) was discovered in Xen, with fixes available for 4.8.x, 4.7.x, 4.6.x, 4.5.x, and 4.4.x. The earlier XSA-29 fix introduced an insufficient check on XENMEMexchange input, allowing the caller to drive hypervisor memory accesses outside of the guest provided input/output arrays.

Xen 4.2.x and 4.3.x, when using Intel VT-d for PCI passthrough, does not properly flush the TLB after clearing a present translation table entry, which allows local guest administrators to cause a denial of service or gain privileges via unspecified vectors related to an "inverted boolean parameter."

The pygrub boot loader emulator in Xen, when S-expression output format is requested, allows local pygrub-using guest OS administrators to read or delete arbitrary files on the host via string quotes and S-expressions in the bootloader configuration file.

A flaw memory leak in the Linux Kernel XDP (eXpress Data Path) was found. It can lead to denial of service for some specific configurations like if the non root privileged user from the host system can send malicious packets to the guest systems. This flaw actual for the Linux Kernel versions 5.9 - 5.18.

References: https://www.openwall.com/lists/oss-security/2022/07/05/5 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/xen-netfront.c?h=v5.19-rc7&id=f63c2c2032c2e3caad9add3b82cc6e91c376fd26

The Intel EPT paging code uses an optimization to defer flushing of any cached EPT state until the p2m lock is dropped, so that multiple modifications done under the same locked region only issue a single flush.

Freeing of paging structures however is not deferred until the flushing is done, and can result in freed pages transiently being present in cached state. Such stale entries can point to memory ranges not owned by the guest, thus allowing access to unintended memory regions.

The adjustments made for XSA-379 as well as those subsequently becoming XSA-387 still left a race window, when a HVM or PVH guest does a grant table version change from v2 to v1 in parallel with mapping the status page(s) via XENMEMaddtophysmap. Some of the status pages may then be freed while mappings of them would still be inserted into the guest's secondary (P2M) page tables.

A flaw was found in the way the Linux kernel handled exceptions delivered after a stack switch operation via Mov SS or Pop SS instructions. During the stack switch operation, processor does not deliver interrupts and exceptions, they are delivered once the first instruction after the stack switch is executed.

An unprivileged system user could use this flaw to crash the system kernel resulting in DoS.

Upstream patch: --------------- -> https://git.kernel.org/linus/d8ba61ba58c88d5207c1ba2f7d9a2280e7d03be9

Reference: ---------- -> http://www.openwall.com/lists/oss-security/2018/05/08/4

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

An issue was discovered in Xen through 4.9.x allowing x86 PV guest OS users to execute arbitrary code on the host OS because of a race condition that can cause a stale TLB entry.

Xen through 4.8.x allows local 64-bit x86 HVM guest OS users to gain privileges by leveraging mishandling of SYSCALL singlestep during emulation.

The x86 emulator in Xen does not properly treat x86 NULL segments as unusable when accessing memory, which might allow local HVM guest users to gain privileges via vectors involving "unexpected" base/limit values.

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.

An issue was discovered in xenvifsethashmapping in drivers/net/xen-netback/hash.c in the Linux kernel through 4.18.1, as used in Xen through 4.11.x and other products. The Linux netback driver allows frontends to control mapping of requests to request queues. When processing a request to set or change this mapping, some input validation (e.g., for an integer overflow) was missing or flawed, leading to OOB access in hash handling. A malicious or buggy frontend may cause the (usually privileged) backend to make out of bounds memory accesses, potentially resulting in one or more of privilege escalation, Denial of Service (DoS), or information leaks.

An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service or possibly gain privileges because of missing memory barriers in read-write unlock paths. The read-write unlock paths don't contain a memory barrier. On Arm, this means a processor is allowed to re-order the memory access with the preceding ones. In other words, the unlock may be seen by another processor before all the memory accesses within the "critical" section. As a consequence, it may be possible to have a writer executing a critical section at the same time as readers or another writer. In other words, many of the assumptions (e.g., a variable cannot be modified after a check) in the critical sections are not safe anymore. The read-write locks are used in hypercalls (such as grant-table ones), so a malicious guest could exploit the race. For instance, there is a small window where Xen can leak memory if XENMAPSPACEgranttable is used concurrently. A malicious guest may be able to leak memory, or cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded.