Total
8485 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2020-15706 | 6 Canonical, Debian, Gnu and 3 more | 13 Ubuntu Linux, Debian Linux, Grub2 and 10 more | 2024-11-21 | 4.4 MEDIUM | 6.4 MEDIUM |
| GRUB2 contains a race condition in grub_script_function_create() leading to a use-after-free vulnerability which can be triggered by redefining a function whilst the same function is already executing, leading to arbitrary code execution and secure boot restriction bypass. This issue affects GRUB2 version 2.04 and prior versions. | |||||
| CVE-2020-15705 | 7 Canonical, Debian, Gnu and 4 more | 14 Ubuntu Linux, Debian Linux, Grub2 and 11 more | 2024-11-21 | 4.4 MEDIUM | 6.4 MEDIUM |
| GRUB2 fails to validate kernel signature when booted directly without shim, allowing secure boot to be bypassed. This only affects systems where the kernel signing certificate has been imported directly into the secure boot database and the GRUB image is booted directly without the use of shim. This issue affects GRUB2 version 2.04 and prior versions. | |||||
| CVE-2020-15683 | 3 Debian, Mozilla, Opensuse | 5 Debian Linux, Firefox, Firefox Esr and 2 more | 2024-11-21 | 7.5 HIGH | 9.8 CRITICAL |
| Mozilla developers and community members reported memory safety bugs present in Firefox 81 and Firefox ESR 78.3. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR < 78.4, Firefox < 82, and Thunderbird < 78.4. | |||||
| CVE-2020-15673 | 3 Debian, Mozilla, Opensuse | 5 Debian Linux, Firefox, Firefox Esr and 2 more | 2024-11-21 | 6.8 MEDIUM | 8.8 HIGH |
| Mozilla developers reported memory safety bugs present in Firefox 80 and Firefox ESR 78.2. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 81, Thunderbird < 78.3, and Firefox ESR < 78.3. | |||||
| CVE-2020-15586 | 5 Cloudfoundry, Debian, Fedoraproject and 2 more | 6 Cf-deployment, Routing-release, Debian Linux and 3 more | 2024-11-21 | 4.3 MEDIUM | 5.9 MEDIUM |
| Go before 1.13.13 and 1.14.x before 1.14.5 has a data race in some net/http servers, as demonstrated by the httputil.ReverseProxy Handler, because it reads a request body and writes a response at the same time. | |||||
| CVE-2020-15567 | 4 Debian, Fedoraproject, Opensuse and 1 more | 4 Debian Linux, Fedora, Leap and 1 more | 2024-11-21 | 4.4 MEDIUM | 7.8 HIGH |
| An issue was discovered in Xen through 4.13.x, allowing Intel guest OS users to gain privileges or cause a denial of service because of non-atomic modification of a live EPT PTE. When mapping guest EPT (nested paging) tables, Xen would in some circumstances use a series of non-atomic bitfield writes. Depending on the compiler version and optimisation flags, Xen might expose a dangerous partially written PTE to the hardware, which an attacker might be able to race to exploit. A guest administrator or perhaps even an unprivileged guest user might be able to cause denial of service, data corruption, or privilege escalation. Only systems using Intel CPUs are vulnerable. Systems using AMD CPUs, and Arm systems, are not vulnerable. Only systems using nested paging (hap, aka nested paging, aka in this case Intel EPT) are vulnerable. Only HVM and PVH guests can exploit the vulnerability. The presence and scope of the vulnerability depends on the precise optimisations performed by the compiler used to build Xen. If the compiler generates (a) a single 64-bit write, or (b) a series of read-modify-write operations in the same order as the source code, the hypervisor is not vulnerable. For example, in one test build using GCC 8.3 with normal settings, the compiler generated multiple (unlocked) read-modify-write operations in source-code order, which did not constitute a vulnerability. We have not been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code (with which code-generation options). The source code clearly violates the C rules, and thus should be considered vulnerable. | |||||
| CVE-2020-15566 | 2 Debian, Xen | 2 Debian Linux, Xen | 2024-11-21 | 4.7 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a host OS crash because of incorrect error handling in event-channel port allocation. The allocation of an event-channel port may fail for multiple reasons: (1) port is already in use, (2) the memory allocation failed, or (3) the port we try to allocate is higher than what is supported by the ABI (e.g., 2L or FIFO) used by the guest or the limit set by an administrator (max_event_channels in xl cfg). Due to the missing error checks, only (1) will be considered an error. All the other cases will provide a valid port and will result in a crash when trying to access the event channel. When the administrator configured a guest to allow more than 1023 event channels, that guest may be able to crash the host. When Xen is out-of-memory, allocation of new event channels will result in crashing the host rather than reporting an error. Xen versions 4.10 and later are affected. All architectures are affected. The default configuration, when guests are created with xl/libxl, is not vulnerable, because of the default event-channel limit. | |||||
| CVE-2020-15565 | 4 Debian, Fedoraproject, Opensuse and 1 more | 4 Debian Linux, Fedora, Leap and 1 more | 2024-11-21 | 6.1 MEDIUM | 8.8 HIGH |
| An issue was discovered in Xen through 4.13.x, allowing x86 Intel HVM guest OS users to cause a host OS denial of service or possibly gain privileges because of insufficient cache write-back under VT-d. When page tables are shared between IOMMU and CPU, changes to them require flushing of both TLBs. Furthermore, IOMMUs may be non-coherent, and hence prior to flushing IOMMU TLBs, a CPU cache also needs writing back to memory after changes were made. Such writing back of cached data was missing in particular when splitting large page mappings into smaller granularity ones. A malicious guest may be able to retain read/write DMA access to frames returned to Xen's free pool, and later reused for another purpose. Host crashes (leading to a Denial of Service) and privilege escalation cannot be ruled out. Xen versions from at least 3.2 onwards are affected. Only x86 Intel systems are affected. x86 AMD as well as Arm systems are not affected. Only x86 HVM guests using hardware assisted paging (HAP), having a passed through PCI device assigned, and having page table sharing enabled can leverage the vulnerability. Note that page table sharing will be enabled (by default) only if Xen considers IOMMU and CPU large page size support compatible. | |||||
| CVE-2020-15564 | 3 Debian, Fedoraproject, Xen | 3 Debian Linux, Fedora, Xen | 2024-11-21 | 4.9 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.13.x, allowing Arm guest OS users to cause a hypervisor crash because of a missing alignment check in VCPUOP_register_vcpu_info. The hypercall VCPUOP_register_vcpu_info is used by a guest to register a shared region with the hypervisor. The region will be mapped into Xen address space so it can be directly accessed. On Arm, the region is accessed with instructions that require a specific alignment. Unfortunately, there is no check that the address provided by the guest will be correctly aligned. As a result, a malicious guest could cause a hypervisor crash by passing a misaligned address. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of Service (DoS). All Xen versions are vulnerable. Only Arm systems are vulnerable. x86 systems are not affected. | |||||
| CVE-2020-15563 | 4 Debian, Fedoraproject, Opensuse and 1 more | 4 Debian Linux, Fedora, Leap and 1 more | 2024-11-21 | 4.7 MEDIUM | 6.5 MEDIUM |
| An issue was discovered in Xen through 4.13.x, allowing x86 HVM guest OS users to cause a hypervisor crash. An inverted conditional in x86 HVM guests' dirty video RAM tracking code allows such guests to make Xen de-reference a pointer guaranteed to point at unmapped space. A malicious or buggy HVM guest may cause the hypervisor to crash, resulting in Denial of Service (DoS) affecting the entire host. Xen versions from 4.8 onwards are affected. Xen versions 4.7 and earlier are not affected. Only x86 systems are affected. Arm systems are not affected. Only x86 HVM guests using shadow paging can leverage the vulnerability. In addition, there needs to be an entity actively monitoring a guest's video frame buffer (typically for display purposes) in order for such a guest to be able to leverage the vulnerability. x86 PV guests, as well as x86 HVM guests using hardware assisted paging (HAP), cannot leverage the vulnerability. | |||||
| CVE-2020-15562 | 2 Debian, Roundcube | 2 Debian Linux, Webmail | 2024-11-21 | 4.3 MEDIUM | 6.1 MEDIUM |
| An issue was discovered in Roundcube Webmail before 1.2.11, 1.3.x before 1.3.14, and 1.4.x before 1.4.7. It allows XSS via a crafted HTML e-mail message, as demonstrated by a JavaScript payload in the xmlns (aka XML namespace) attribute of a HEAD element when an SVG element exists. | |||||
| CVE-2020-15476 | 3 Debian, Linux, Ntop | 3 Debian Linux, Linux Kernel, Ndpi | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| In nDPI through 3.2, the Oracle protocol dissector has a heap-based buffer over-read in ndpi_search_oracle in lib/protocols/oracle.c. | |||||
| CVE-2020-15472 | 2 Debian, Ntop | 2 Debian Linux, Ndpi | 2024-11-21 | 6.4 MEDIUM | 9.1 CRITICAL |
| In nDPI through 3.2, the H.323 dissector is vulnerable to a heap-based buffer over-read in ndpi_search_h323 in lib/protocols/h323.c, as demonstrated by a payload packet length that is too short. | |||||
| CVE-2020-15469 | 2 Debian, Qemu | 2 Debian Linux, Qemu | 2024-11-21 | 2.1 LOW | 2.3 LOW |
| In QEMU 4.2.0, a MemoryRegionOps object may lack read/write callback methods, leading to a NULL pointer dereference. | |||||
| CVE-2020-15466 | 3 Debian, Opensuse, Wireshark | 3 Debian Linux, Leap, Wireshark | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| In Wireshark 3.2.0 to 3.2.4, the GVCP dissector could go into an infinite loop. This was addressed in epan/dissectors/packet-gvcp.c by ensuring that an offset increases in all situations. | |||||
| CVE-2020-15393 | 4 Canonical, Debian, Linux and 1 more | 4 Ubuntu Linux, Debian Linux, Linux Kernel and 1 more | 2024-11-21 | 2.1 LOW | 5.5 MEDIUM |
| In the Linux kernel 4.4 through 5.7.6, usbtest_disconnect in drivers/usb/misc/usbtest.c has a memory leak, aka CID-28ebeb8db770. | |||||
| CVE-2020-15389 | 3 Debian, Oracle, Uclouvain | 3 Debian Linux, Outside In Technology, Openjpeg | 2024-11-21 | 5.8 MEDIUM | 6.5 MEDIUM |
| jp2/opj_decompress.c in OpenJPEG through 2.3.1 has a use-after-free that can be triggered if there is a mix of valid and invalid files in a directory operated on by the decompressor. Triggering a double-free may also be possible. This is related to calling opj_image_destroy twice. | |||||
| CVE-2020-15306 | 5 Canonical, Debian, Fedoraproject and 2 more | 5 Ubuntu Linux, Debian Linux, Fedora and 2 more | 2024-11-21 | 2.1 LOW | 5.5 MEDIUM |
| An issue was discovered in OpenEXR before v2.5.2. Invalid chunkCount attributes could cause a heap buffer overflow in getChunkOffsetTableSize() in IlmImf/ImfMisc.cpp. | |||||
| CVE-2020-15305 | 5 Canonical, Debian, Fedoraproject and 2 more | 5 Ubuntu Linux, Debian Linux, Fedora and 2 more | 2024-11-21 | 2.1 LOW | 5.5 MEDIUM |
| An issue was discovered in OpenEXR before 2.5.2. Invalid input could cause a use-after-free in DeepScanLineInputFile::DeepScanLineInputFile() in IlmImf/ImfDeepScanLineInputFile.cpp. | |||||
| CVE-2020-15257 | 3 Debian, Fedoraproject, Linuxfoundation | 3 Debian Linux, Fedora, Containerd | 2024-11-21 | 3.6 LOW | 5.2 MEDIUM |
| containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows. In containerd before versions 1.3.9 and 1.4.3, the containerd-shim API is improperly exposed to host network containers. Access controls for the shim’s API socket verified that the connecting process had an effective UID of 0, but did not otherwise restrict access to the abstract Unix domain socket. This would allow malicious containers running in the same network namespace as the shim, with an effective UID of 0 but otherwise reduced privileges, to cause new processes to be run with elevated privileges. This vulnerability has been fixed in containerd 1.3.9 and 1.4.3. Users should update to these versions as soon as they are released. It should be noted that containers started with an old version of containerd-shim should be stopped and restarted, as running containers will continue to be vulnerable even after an upgrade. If you are not providing the ability for untrusted users to start containers in the same network namespace as the shim (typically the "host" network namespace, for example with docker run --net=host or hostNetwork: true in a Kubernetes pod) and run with an effective UID of 0, you are not vulnerable to this issue. If you are running containers with a vulnerable configuration, you can deny access to all abstract sockets with AppArmor by adding a line similar to deny unix addr=@**, to your policy. It is best practice to run containers with a reduced set of privileges, with a non-zero UID, and with isolated namespaces. The containerd maintainers strongly advise against sharing namespaces with the host. Reducing the set of isolation mechanisms used for a container necessarily increases that container's privilege, regardless of what container runtime is used for running that container. | |||||