| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An issue was discovered in Xen through 4.14.x. There are evtchn_reset() race conditions. Uses of EVTCHNOP_reset (potentially by a guest on itself) or XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the violation of various internal assumptions. This may lead to out of bounds memory accesses or triggering of bug checks. In particular, x86 PV guests may be able to elevate their privilege to that of the host. Host and guest crashes are also possible, leading to a Denial of Service (DoS). Information leaks cannot be ruled out. All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier are not vulnerable. |
| An issue was discovered in Xen 4.14.x. There is a missing unlock in the XENMEM_acquire_resource error path. The RCU (Read, Copy, Update) mechanism is a synchronisation primitive. A buggy error path in the XENMEM_acquire_resource exits without releasing an RCU reference, which is conceptually similar to forgetting to unlock a spinlock. A buggy or malicious HVM stubdomain can cause an RCU reference to be leaked. This causes subsequent administration operations, (e.g., CPU offline) to livelock, resulting in a host Denial of Service. The buggy codepath has been present since Xen 4.12. Xen 4.14 and later are vulnerable to the DoS. The side effects are believed to be benign on Xen 4.12 and 4.13, but patches are provided nevertheless. The vulnerability can generally only be exploited by x86 HVM VMs, as these are generally the only type of VM that have a Qemu stubdomain. x86 PV and PVH domains, as well as ARM VMs, typically don't use a stubdomain. Only VMs using HVM stubdomains can exploit the vulnerability. VMs using PV stubdomains, or with emulators running in dom0, cannot exploit the vulnerability. |
| An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that an event channel, once valid, will not become invalid over the life time of a guest. However, operations like the resetting of all event channels may involve decreasing one of the bounds checked when determining validity. This may lead to bug checks triggering, crashing the host. An unprivileged guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only systems with untrusted guests permitted to create more than the default number of event channels are vulnerable. This number depends on the architecture and type of guest. For 32-bit x86 PV guests, this is 1023; for 64-bit x86 PV guests, and for all ARM guests, this number is 4095. Systems where untrusted guests are limited to fewer than this number are not vulnerable. Note that xl and libxl limit max_event_channels to 1023 by default, so systems using exclusively xl, libvirt+libxl, or their own toolstack based on libxl, and not explicitly setting max_event_channels, are not vulnerable. |
| An issue was discovered in Xen through 4.14.x. x86 PV guest kernels can experience denial of service via SYSENTER. The SYSENTER instruction leaves various state sanitization activities to software. One of Xen's sanitization paths injects a #GP fault, and incorrectly delivers it twice to the guest. This causes the guest kernel to observe a kernel-privilege #GP fault (typically fatal) rather than a user-privilege #GP fault (usually converted into SIGSEGV/etc.). Malicious or buggy userspace can crash the guest kernel, resulting in a VM Denial of Service. All versions of Xen from 3.2 onwards are vulnerable. Only x86 systems are vulnerable. ARM platforms are not vulnerable. Only x86 systems that support the SYSENTER instruction in 64bit mode are vulnerable. This is believed to be Intel, Centaur, and Shanghai CPUs. AMD and Hygon CPUs are not believed to be vulnerable. Only x86 PV guests can exploit the vulnerability. x86 PVH / HVM guests cannot exploit the vulnerability. |
| An issue was discovered in Xen through 4.14.x. The PCI passthrough code improperly uses register data. Code paths in Xen's MSI handling have been identified that act on unsanitized values read back from device hardware registers. While devices strictly compliant with PCI specifications shouldn't be able to affect these registers, experience shows that it's very common for devices to have out-of-spec "backdoor" operations that can affect the result of these reads. A not fully trusted guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. Privilege escalation and information leaks cannot be excluded. All versions of Xen supporting PCI passthrough are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only guests with passed through PCI devices may be able to leverage the vulnerability. Only systems passing through devices with out-of-spec ("backdoor") functionality can cause issues. Experience shows that such out-of-spec functionality is common; unless you have reason to believe that your device does not have such functionality, it's better to assume that it does. |
| HashiCorp Vault and Vault Enterprise allowed for enumeration of Secrets Engine mount paths via unauthenticated HTTP requests. Fixed in 1.6.2 & 1.5.7. |
| Acronis True Image through 2021 on macOS allows local privilege escalation from admin to root due to insecure folder permissions. |
| In SaltStack Salt through 3002, salt-netapi improperly validates eauth credentials and tokens. A user can bypass authentication and invoke Salt SSH. |
| In FreeBSD 13.0-STABLE before n245118, 12.2-STABLE before r369552, 11.4-STABLE before r369560, 13.0-RC5 before p1, 12.2-RELEASE before p6, and 11.4-RELEASE before p9, a superuser inside a FreeBSD jail configured with the non-default allow.mount permission could cause a race condition between the lookup of ".." and remounting a filesystem, allowing access to filesystem hierarchy outside of the jail. |
| In FreeBSD 12.2-STABLE before r368250, 11.4-STABLE before r368253, 12.2-RELEASE before p1, 12.1-RELEASE before p11 and 11.4-RELEASE before p5 when processing a DNSSL option, rtsold(8) decodes domain name labels per an encoding specified in RFC 1035 in which the first octet of each label contains the label's length. rtsold(8) did not validate label lengths correctly and could overflow the destination buffer. |
| In FreeBSD 12.2-STABLE before r369334, 11.4-STABLE before r369335, 12.2-RELEASE before p4 and 11.4-RELEASE before p8 when a process, such as jexec(8) or killall(1), calls jail_attach(2) to enter a jail, the jailed root can attach to it using ptrace(2) before the current working directory is changed. |
| In FreeBSD 12.2-STABLE before r369312, 11.4-STABLE before r369313, 12.2-RELEASE before p4 and 11.4-RELEASE before p8 due to a race condition in the jail_remove(2) implementation, it may fail to kill some of the processes. |
| In FreeBSD 12.2-STABLE before r369346, 11.4-STABLE before r369345, 12.2-RELEASE before p4 and 11.4-RELEASE before p8 a regression in the login.access(5) rule processor has the effect of causing rules to fail to match even when they should not. This means that rules denying access may be ignored. |
| In FreeBSD 12.2-STABLE before r368969, 11.4-STABLE before r369047, 12.2-RELEASE before p3, 12.1-RELEASE before p13 and 11.4-RELEASE before p7 msdosfs(5) was failing to zero-fill a pair of padding fields in the dirent structure, resulting in a leak of three uninitialized bytes. |
| In FreeBSD 12.2-STABLE before r368969, 11.4-STABLE before r369047, 12.2-RELEASE before p3, 12.1-RELEASE before p13 and 11.4-RELEASE before p7 several file systems were not properly initializing the d_off field of the dirent structures returned by VOP_READDIR. In particular, tmpfs(5), smbfs(5), autofs(5) and mqueuefs(5) were failing to do so. As a result, eight uninitialized kernel stack bytes may be leaked to userspace by these file systems. |
| In FreeBSD 12.2-STABLE before r368250, 11.4-STABLE before r368253, 12.2-RELEASE before p1, 12.1-RELEASE before p11 and 11.4-RELEASE before p5 rtsold(8) does not verify that the RDNSS option does not extend past the end of the received packet before processing its contents. While the kernel currently ignores such malformed packets, it passes them to userspace programs. Any programs expecting the kernel to do validation may be vulnerable to an overflow. |
| An issue was discovered in the rand_core crate before 0.4.2 for Rust. Casting of byte slices to integer slices mishandles alignment constraints. |
| An issue was discovered in the failure crate through 0.1.5 for Rust. It may introduce "compatibility hazards" in some applications, and has a type confusion flaw when downcasting. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. NOTE: This may overlap CVE-2019-25010 |
| An issue was discovered in the http crate before 0.1.20 for Rust. An integer overflow in HeaderMap::reserve() could result in denial of service (e.g., an infinite loop). |
| An issue was discovered in the linked-hash-map crate before 0.5.3 for Rust. It creates an uninitialized NonNull pointer, which violates a non-null constraint. |
