Dell EMC RecoverPoint versions prior to 5.1.2.1 and RecoverPoint for VMs versions prior to 5.2.0.2 contain an uncontrolled resource consumption vulnerability. A malicious boxmgmt user may potentially be able to consume large amount of CPU bandwidth to make the system slow or to determine the existence of any system file via Boxmgmt CLI.
CWE-400
CVE-2018-15671
An issue was discovered in the HDF HDF5 1.10.2 library. Excessive stack consumption has been detected in the function H5P__get_cb() in H5Pint.c during an attempted parse of a crafted HDF file. This results in denial of service.
CVE-2018-15607
In ImageMagick 7.0.8-11 Q16, a tiny input file 0x50 0x36 0x36 0x36 0x36 0x4c 0x36 0x38 0x36 0x36 0x36 0x36 0x36 0x36 0x1f 0x35 0x50 0x00 can result in a hang of several minutes during which CPU and memory resources are consumed until ultimately an attempted large memory allocation fails. Remote attackers could leverage this vulnerability to cause a denial of service via a crafted file.
CVE-2018-15464
A vulnerability in Cisco 900 Series Aggregation Services Router (ASR) software could allow an unauthenticated, remote attacker to cause a partial denial of service (DoS) condition on an affected device. The vulnerability is due to insufficient handling of certain broadcast packets ingress to the device. An attacker could exploit this vulnerability by sending large streams of broadcast packets to an affected device. If successful, an exploit could allow an attacker to impact services running on the device, resulting in a partial DoS condition.
CVE-2018-15469
An issue was discovered in Xen through 4.11.x. ARM never properly implemented grant table v2, either in the hypervisor or in Linux. Unfortunately, an ARM guest can still request v2 grant tables; they will simply not be properly set up, resulting in subsequent grant-related hypercalls hitting BUG() checks. An unprivileged guest can cause a BUG() check in the hypervisor, resulting in a denial-of-service (crash).
CVE-2018-15470
An issue was discovered in Xen through 4.11.x. The logic in oxenstored for handling writes depended on the order of evaluation of expressions making up a tuple. As indicated in section 7.7.3 “Operations on data structures” of the OCaml manual, the order of evaluation of subexpressions is not specified. In practice, different implementations behave differently. Thus, oxenstored may not enforce the configured quota-maxentity. This allows a malicious or buggy guest to write as many xenstore entries as it wishes, causing unbounded memory usage in oxenstored. This can lead to a system-wide DoS.