Jürgen Groß

The closing of an event channel in the Linux kernel can result in a deadlock. This happens when the close is being performed in parallel to an unrelated Xen console action and the handling of a Xen console interrupt in an unprivileged guest. The closing of an event channel is triggered by removal of a paravirtual device on the other side, which can cause console messages to be issued on the other side quite often, making the chance of triggering the deadlock not neglectable. Note that 32-bit Arm-guests are not affected, as the 32-bit Linux kernel on Arm doesn't use queued-RW-locks, which are required to trigger the issue.

The issue arises from the Ocaml Xenbus library taking a C uint32 t out of the ring and casting it directly to an Ocaml integer. In 32-bit builds, this causes a truncation of the most significant bit, leading to unsigned/signed confusion. As a result, a negative value can be fed into logic that does not expect it, causing unexpected exceptions. These exceptions are not handled properly, resulting in a busy-loop that attempts to remove a bad packet from the xenstore ring.

The issue is related to the Xenstore component of the Xen hypervisor, where guests can gain access to Xenstore nodes of deleted domains due to incomplete cleanup of temporary or auxiliary resources. This can lead to unauthorized access to protected information, privilege escalation, or denial of service. The problem occurs when a new domain is created with the same domid as a previously removed domain, and there is a small time window where the access rights of the past domain are still considered valid. For this to happen, another domain needs to write the node before the newly created domain is introduced to Xenstore by dom0.

The issue allows cooperating guests to create an arbitrary number of Xenstore nodes. This is possible when one guest lets another write into its local Xenstore tree, creating many nodes and then rebooting. The nodes created will be owned by Dom0, which has no limit on the number of nodes it can own due to Xenstore quota. This can lead to a denial of service.

The issue allows cooperating guests to create an arbitrary number of Xenstore nodes. This is possible when one domain lets another write into its local Xenstore tree, creating many nodes and then rebooting. The created nodes become owned by Dom0, which has no limit on the number of nodes due to Xenstore quota. This can lead to a denial of service.

The netback driver vulnerability in the Linux kernel is related to resource release errors. Exploitation of this issue may allow an attacker to cause a denial of service.

The issue is related to a driver vulnerability in the Linux kernel's netback component, which is associated with resource release errors. Exploitation of this issue could allow an attacker to cause a denial of service.

The issue is related to an uncontrolled resource consumption in the hvc xen (console) component of the Xen hypervisor. It may allow a remote attacker to cause a denial of service.

The issue is related to a component of the Xen hypervisor, specifically the blkfront component, which has a resource release error. This can be exploited by a remote attacker to cause a denial of service.

The issue is related to errors in resource release in the netfront component of the Xen hypervisor. Exploitation of this issue may allow an attacker to cause a denial of service.

An issue was discovered in Xen where access rights of Xenstore nodes are per domid. Unfortunately, existing granted access rights are not removed when a domain is being destroyed, allowing a new domain created with the same domid to inherit the access rights to Xenstore nodes from the previous domain(s) with the same domid. This means a newly created guest domain might be able to read sensitive information that had belonged to a previously existing guest domain. Both Xenstore implementations (C and Ocaml) are vulnerable.

An issue in Xen allows guest OS users to cause a denial of service due to bad continuation handling in GNTTABOP copy. Grant table operations are expected to return 0 for success and a negative number for errors. However, a path through grant copy handling may return success to the caller without any action taken, leaving status fields of individual operations uninitialised. This can result in errant behaviour in the caller of GNTTABOP copy. A buggy or malicious guest can construct its grant table to hit the incorrect exit path when a backend domain tries to copy a grant, returning success without doing anything, which may cause crashes or other incorrect behaviour.