Edwin Török

**Name of the Vulnerable Software and Affected Versions** Xen XAPI versions prior to 2020-12-15 **Description** An issue was discovered in Xen XAPI where certain xenstore keys provide feedback from the guest and are watched by toolstack, specifically by xenopsd. The watching logic in xenopsd sends one RPC update containing all data any time a single xenstore key is updated, resulting in O(N^2) time complexity. Furthermore, message-switch retains recent RPC messages for diagnostic purposes, yielding O(M*N) space complexity. A buggy or malicious guest can cause unreasonable memory usage in dom0, resulting in a host denial of service. The quantity of memory a single guest can monopolize is bounded by xenstored quota, which is fairly large, believed to be in excess of 1G per malicious guest. **Recommendations** As a temporary workaround, consider disabling the xenopsd watching logic until a patch is available. Restrict access to the xenstore keys to minimize the risk of exploitation. Avoid using the RPC update feature in xenopsd until the issue is resolved. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Xen versions prior to 4.14.x **Description** The issue is related to the oxenstored process of the Xen hypervisor, which is associated with unbounded memory allocation. Exploitation of this issue can allow an attacker to cause a denial of service. In oxenstored, a node owner could give a node away, but node ownership has quota implications. Any guest can run another guest out of quota or create an unbounded number of nodes owned by dom0, thus running xenstored out of memory. A malicious guest administrator can cause a denial of service against a specific guest or against the whole host. All systems using oxenstored are vulnerable. **Recommendations** For Xen versions prior to 4.14.x, consider disabling the use of oxenstored as a temporary workaround until a patch is available. Restrict access to the xenstore nodes to minimize the risk of exploitation. Avoid using the oxenstored process in the upstream Xen distribution if the Ocaml compiler is available, and instead use C xenstored, which is not vulnerable.

**Name of the Vulnerable Software and Affected Versions** Xen versions prior to 4.14.x **Description** The issue is related to the implementation of Ocaml xenstored in Xen, where the internal representation of the tree has special cases for the root node. Unfortunately, permissions were not checked for certain operations on the root node, allowing unprivileged guests to get and modify permissions, list, and delete the root node. This can lead to a host-wide denial of service if the whole xenstore tree is deleted. Achieving xenstore write access is also possible. All systems using oxenstored are vulnerable, while systems using C xenstored are not. **Recommendations** For Xen versions prior to 4.14.x, consider disabling the use of oxenstored as a temporary workaround until a patch is available. Restrict access to the xenstore tree to minimize the risk of exploitation. Avoid using the oxenstored implementation until the issue is resolved. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Xen versions through 4.14.x **Description** An issue was discovered in Xen where a guest may access xenstore paths via absolute paths containing a full pathname, or via a relative path, which implicitly includes `/local/domain/$DOMID` for their own domain id. Management tools must access paths in guests' namespaces, necessarily using absolute paths. oxenstored imposes a pathname limit that is applied solely to the relative or absolute path specified by the client. Therefore, a guest can create paths in its own namespace which are too long for management tools to access. Depending on the toolstack in use, a malicious guest administrator might cause some management tools and debugging operations to fail. For example, a guest administrator can cause "xenstore-ls -r" to fail. However, a guest administrator cannot prevent the host administrator from tearing down the domain. All systems using oxenstored are vulnerable. **Recommendations** As a temporary workaround, consider restricting access to the `xenstore` paths to minimize the risk of exploitation. To resolve the issue, ensure that the Ocaml compiler is not available or switch to using C xenstored, as systems using C xenstored are not vulnerable. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Dnsmasq versions prior to 2.76 **Description** The issue allows remote servers to cause a denial of service (crash) via a reply with an empty DNS address that has an (1) A or (2) AAAA record defined locally. **Recommendations** For versions prior to 2.76, update to version 2.76 or later to resolve the issue.