Total
708 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2020-20665 | 1 Rudp Project | 1 Rudp | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| rudp v0.6 was discovered to contain a memory leak in the component main.c. | |||||
| CVE-2020-20451 | 2 Debian, Ffmpeg | 2 Debian Linux, Ffmpeg | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| Denial of Service issue in FFmpeg 4.2 due to resource management errors via fftools/cmdutils.c. | |||||
| CVE-2020-1883 | 1 Huawei | 6 Nip6800, Nip6800 Firmware, Secospace Usg6600 and 3 more | 2024-11-21 | 4.0 MEDIUM | 4.9 MEDIUM |
| Huawei products NIP6800;Secospace USG6600;USG9500 have a memory leak vulnerability. An attacker with high privileges exploits this vulnerability by continuously performing specific operations. Successful exploitation of this vulnerability can cause service abnormal. | |||||
| CVE-2020-1815 | 1 Huawei | 6 Nip6800, Nip6800 Firmware, Secospace Usg6600 and 3 more | 2024-11-21 | 4.3 MEDIUM | 7.5 HIGH |
| Huawei NIP6800 versions V500R001C30, V500R001C60SPC500, and V500R005C00; Secospace USG6600 and USG9500 versions V500R001C30SPC200, V500R001C30SPC600, V500R001C60SPC500, and V500R005C00 have a memory leak vulnerability. The software does not sufficiently track and release allocated memory while parse certain message, the attacker sends the message continuously that could consume remaining memory. Successful exploit could cause memory exhaust. | |||||
| CVE-2020-1683 | 1 Juniper | 1 Junos | 2024-11-21 | 7.8 HIGH | 7.5 HIGH |
| On Juniper Networks Junos OS devices, a specific SNMP OID poll causes a memory leak which over time leads to a kernel crash (vmcore). Prior to the kernel crash other processes might be impacted, such as failure to establish SSH connection to the device. The administrator can monitor the output of the following command to check if there is memory leak caused by this issue: user@device> show system virtual-memory | match "pfe_ipc|kmem" pfe_ipc 147 5K - 164352 16,32,64,8192 <-- increasing vm.kmem_map_free: 127246336 <-- decreasing pfe_ipc 0 0K - 18598 32,8192 vm.kmem_map_free: 134582272 This issue affects Juniper Networks Junos OS: 17.4R3; 18.1 version 18.1R3-S5 and later versions prior to 18.1R3-S10; 18.2 version 18.2R3 and later versions prior to 18.2R3-S3; 18.2X75 version 18.2X75-D420, 18.2X75-D50 and later versions prior to 18.2X75-D430, 18.2X75-D53, 18.2X75-D60; 18.3 version 18.3R3 and later versions prior to 18.3R3-S2; 18.4 version 18.4R1-S4, 18.4R2 and later versions prior to 18.4R2-S5, 18.4R3-S1; 19.1 version 19.1R2 and later versions prior to 19.1R2-S2, 19.1R3; 19.2 version 19.2R1 and later versions prior to 19.2R1-S5, 19.2R2; 19.3 versions prior to 19.3R2-S5, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2. This issue does not affect Juniper Networks Junos OS prior to 17.4R3. | |||||
| CVE-2020-1678 | 1 Juniper | 2 Junos, Junos Os Evolved | 2024-11-21 | 2.9 LOW | 6.5 MEDIUM |
| On Juniper Networks Junos OS and Junos OS Evolved platforms with EVPN configured, receipt of specific BGP packets causes a slow memory leak. If the memory is exhausted the rpd process might crash. If the issue occurs, the memory leak could be seen by executing the "show task memory detail | match policy | match evpn" command multiple times to check if memory (Alloc Blocks value) is increasing. root@device> show task memory detail | match policy | match evpn ------------------------ Allocator Memory Report ------------------------ Name | Size | Alloc DTXP Size | Alloc Blocks | Alloc Bytes | MaxAlloc Blocks | MaxAlloc Bytes Policy EVPN Params 20 24 3330678 79936272 3330678 79936272 root@device> show task memory detail | match policy | match evpn ------------------------ Allocator Memory Report ------------------------ Name | Size | Alloc DTXP Size | Alloc Blocks | Alloc Bytes | MaxAlloc Blocks | MaxAlloc Bytes Policy EVPN Params 20 24 36620255 878886120 36620255 878886120 This issue affects: Juniper Networks Junos OS 19.4 versions prior to 19.4R2; 20.1 versions prior to 20.1R1-S4, 20.1R2; Juniper Networks Junos OS Evolved: 19.4 versions; 20.1 versions prior to 20.1R1-S4-EVO, 20.1R2-EVO; 20.2 versions prior to 20.2R1-EVO; This issue does not affect: Juniper Networks Junos OS releases prior to 19.4R1. Juniper Networks Junos OS Evolved releases prior to 19.4R1-EVO. | |||||
| CVE-2020-1651 | 1 Juniper | 16 Junos, Mx10, Mx10000 and 13 more | 2024-11-21 | 3.3 LOW | 6.5 MEDIUM |
| On Juniper Networks MX series, receipt of a stream of specific Layer 2 frames may cause a memory leak resulting in the packet forwarding engine (PFE) on the line card to crash and restart, causing traffic interruption. By continuously sending this stream of specific layer 2 frame, an attacker connected to the same broadcast domain can repeatedly crash the PFE, causing a prolonged Denial of Service (DoS). This issue affects Juniper Networks Junos OS on MX Series: 17.2 versions prior to 17.2R3-S4; 17.2X75 versions prior to 17.2X75-D105.19; 17.3 versions prior to 17.3R3-S7; 17.4 versions prior to 17.4R1-S3, 17.4R2; 18.1 versions prior to 18.1R2. This issue does not affect Juniper Networks Junos OS releases prior to 17.2R1. | |||||
| CVE-2020-1625 | 1 Juniper | 1 Junos | 2024-11-21 | 3.3 LOW | 6.5 MEDIUM |
| The kernel memory usage represented as "temp" via 'show system virtual-memory' may constantly increase when Integrated Routing and Bridging (IRB) is configured with multiple underlay physical interfaces, and one interface flaps. This memory leak can affect running daemons (processes), leading to an extended Denial of Service (DoS) condition. Usage of "temp" virtual memory, shown here by a constantly increasing value of outstanding Requests, can be monitored by executing the 'show system virtual-memory' command as shown below: user@junos> show system virtual-memory |match "fpc|type|temp" fpc0: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2023 431K - 10551 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 fpc1: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2020 431K - 6460 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 user@junos> show system virtual-memory |match "fpc|type|temp" fpc0: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2023 431K - 16101 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 fpc1: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2020 431K - 6665 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 user@junos> show system virtual-memory |match "fpc|type|temp" fpc0: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2023 431K - 21867 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 fpc1: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2020 431K - 6858 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 This issue affects Juniper Networks Junos OS: 16.1 versions prior to 16.1R7-S6; 17.1 versions prior to 17.1R2-S11, 17.1R3-S1; 17.2 versions prior to 17.2R2-S8, 17.2R3-S3; 17.2X75 versions prior to 17.2X75-D44; 17.3 versions prior to 17.3R2-S5, 17.3R3-S6; 17.4 versions prior to 17.4R2-S5, 17.4R3; 18.1 versions prior to 18.1R3-S7; 18.2 versions prior to 18.2R2-S5, 18.2R3; 18.2X75 versions prior to 18.2X75-D33, 18.2X75-D411, 18.2X75-D420, 18.2X75-D60; 18.3 versions prior to 18.3R1-S5, 18.3R2-S3, 18.3R3; 18.4 versions prior to 18.4R2-S2, 18.4R3; 19.1 versions prior to 19.1R1-S3, 19.1R2; 19.2 versions prior to 19.2R1-S3, 19.2R2. This issue does not affect Juniper Networks Junos OS 12.3 and 15.1. | |||||
| CVE-2020-1603 | 1 Juniper | 1 Junos | 2024-11-21 | 7.8 HIGH | 8.6 HIGH |
| Specific IPv6 packets sent by clients processed by the Routing Engine (RE) are improperly handled. These IPv6 packets are designed to be blocked by the RE from egressing the RE. Instead, the RE allows these specific IPv6 packets to egress the RE, at which point a mbuf memory leak occurs within the Juniper Networks Junos OS device. This memory leak eventually leads to a kernel crash (vmcore), or the device hanging and requiring a power cycle to restore service, creating a Denial of Service (DoS) condition. During the time where mbufs are rising, yet not fully filled, some traffic from client devices may begin to be black holed. To be black holed, this traffic must match the condition where this traffic must be processed by the RE. Continued receipt and attempted egress of these specific IPv6 packets from the Routing Engine (RE) will create an extended Denial of Service (DoS) condition. Scenarios which have been observed are: 1. In a single chassis, single RE scenario, the device will hang without vmcore, or a vmcore may occur and then hang. In this scenario the device needs to be power cycled. 2. In a single chassis, dual RE scenario, the device master RE will fail over to the backup RE. In this scenario, the master and the backup REs need to be reset from time to time when they vmcore. There is no need to power cycle the device. 3. In a dual chassis, single RE scenario, the device will hang without vmcore, or a vmcore may occur and then hang. In this scenario, the two chassis' design relies upon some type of network level redundancy - VRRP, GRES, NSR, etc. - 3.a In a commanded switchover, where nonstop active routing (NSR) is enabled no session loss is observed. 4. In a dual chassis, dual chassis scenario, rely upon the RE to RE failover as stated in the second scenario. In the unlikely event that the device does not switch RE to RE gracefully, then the fallback position is to the network level services scenario in the third scenario. This issue affects: Juniper Networks Junos OS 16.1 versions prior to 16.1R7-S6; 16.1 version 16.1X70-D10 and later; 16.2 versions prior to 16.2R2-S11; 17.1 versions prior to 17.1R2-S11, 17.1R3-S1; 17.2 versions prior to 17.2R1-S9, 17.2R2-S8, 17.2R3-S3; 17.3 versions prior to 17.3R3-S6; 17.4 versions prior to 17.4R2-S9, 17.4R3; 18.1 versions prior to 18.1R3-S7; 18.2 versions prior to 18.2R3-S2; 18.2X75 versions prior to 18.2X75-D50, 18.2X75-D410; 18.3 versions prior to 18.3R1-S6, 18.3R2-S2, 18.3R3; 18.4 versions prior to 18.4R1-S6, 18.4R2-S2, 18.4R3; 19.1 versions prior to 19.1R1-S3, 19.1R2; 19.2 versions prior to 19.2R1-S2, 19.2R2. This issue does not affect releases prior to Junos OS 16.1R1. | |||||
| CVE-2020-19724 | 1 Gnu | 1 Binutils | 2024-11-21 | N/A | 5.5 MEDIUM |
| A memory consumption issue in get_data function in binutils/nm.c in GNU nm before 2.34 allows attackers to cause a denial of service via crafted command. | |||||
| CVE-2020-16949 | 1 Microsoft | 11 365 Apps, Office, Outlook and 8 more | 2024-11-21 | 5.0 MEDIUM | 4.7 MEDIUM |
| <p>A denial of service vulnerability exists in Microsoft Outlook software when the software fails to properly handle objects in memory. An attacker who successfully exploited the vulnerability could cause a remote denial of service against a system.</p> <p>Exploitation of the vulnerability requires that a specially crafted email be sent to a vulnerable Outlook server.</p> <p>The security update addresses the vulnerability by correcting how Microsoft Outlook handles objects in memory.</p> | |||||
| CVE-2020-15806 | 1 Codesys | 16 Control For Beaglebone, Control For Empc-a\/imx6, Control For Iot2000 and 13 more | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| CODESYS Control runtime system before 3.5.16.10 allows Uncontrolled Memory Allocation. | |||||
| 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-15254 | 1 Crossbeam Project | 1 Crossbeam | 2024-11-21 | 7.5 HIGH | 8.1 HIGH |
| Crossbeam is a set of tools for concurrent programming. In crossbeam-channel before version 0.4.4, the bounded channel incorrectly assumes that `Vec::from_iter` has allocated capacity that same as the number of iterator elements. `Vec::from_iter` does not actually guarantee that and may allocate extra memory. The destructor of the `bounded` channel reconstructs `Vec` from the raw pointer based on the incorrect assumes described above. This is unsound and causing deallocation with the incorrect capacity when `Vec::from_iter` has allocated different sizes with the number of iterator elements. This has been fixed in crossbeam-channel 0.4.4. | |||||
| CVE-2020-15025 | 4 Netapp, Ntp, Opensuse and 1 more | 27 8300, 8300 Firmware, 8700 and 24 more | 2024-11-21 | 4.0 MEDIUM | 4.4 MEDIUM |
| ntpd in ntp 4.2.8 before 4.2.8p15 and 4.3.x before 4.3.101 allows remote attackers to cause a denial of service (memory consumption) by sending packets, because memory is not freed in situations where a CMAC key is used and associated with a CMAC algorithm in the ntp.keys file. | |||||
| CVE-2020-13934 | 6 Apache, Canonical, Debian and 3 more | 14 Tomcat, Ubuntu Linux, Debian Linux and 11 more | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| An h2c direct connection to Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M5 to 9.0.36 and 8.5.1 to 8.5.56 did not release the HTTP/1.1 processor after the upgrade to HTTP/2. If a sufficient number of such requests were made, an OutOfMemoryException could occur leading to a denial of service. | |||||
| CVE-2020-13152 | 1 Kde | 1 Amarok | 2024-11-21 | 4.3 MEDIUM | 5.5 MEDIUM |
| A remote user can create a specially crafted M3U file, media playlist file that when loaded by the target user, will trigger a memory leak, whereby Amarok 2.8.0 continue to waste resources over time, eventually allows attackers to cause a denial of service. | |||||
| CVE-2020-12887 | 1 Arm | 2 Mbed-coap, Mbed Os | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| Memory leaks were discovered in the CoAP library in Arm Mbed OS 5.15.3 when using the Arm mbed-coap library 5.1.5. The CoAP parser is responsible for parsing received CoAP packets. The function sn_coap_parser_options_parse() parses the CoAP option number field of all options present in the input packet. Each option number is calculated as a sum of the previous option number and a delta of the current option. The delta and the previous option number are expressed as unsigned 16-bit integers. Due to lack of overflow detection, it is possible to craft a packet that wraps the option number around and results in the same option number being processed again in a single packet. Certain options allocate memory by calling a memory allocation function. In the cases of COAP_OPTION_URI_QUERY, COAP_OPTION_URI_PATH, COAP_OPTION_LOCATION_QUERY, and COAP_OPTION_ETAG, there is no check on whether memory has already been allocated, which in conjunction with the option number integer overflow may lead to multiple assignments of allocated memory to a single pointer. This has been demonstrated to lead to memory leak by buffer orphaning. As a result, the memory is never freed. | |||||
| CVE-2020-12768 | 3 Canonical, Debian, Linux | 3 Ubuntu Linux, Debian Linux, Linux Kernel | 2024-11-21 | 2.1 LOW | 5.5 MEDIUM |
| An issue was discovered in the Linux kernel before 5.6. svm_cpu_uninit in arch/x86/kvm/svm.c has a memory leak, aka CID-d80b64ff297e. NOTE: third parties dispute this issue because it's a one-time leak at the boot, the size is negligible, and it can't be triggered at will | |||||
| CVE-2020-12656 | 3 Canonical, Linux, Opensuse | 3 Ubuntu Linux, Linux Kernel, Leap | 2024-11-21 | 2.1 LOW | 5.5 MEDIUM |
| gss_mech_free in net/sunrpc/auth_gss/gss_mech_switch.c in the rpcsec_gss_krb5 implementation in the Linux kernel through 5.6.10 lacks certain domain_release calls, leading to a memory leak. Note: This was disputed with the assertion that the issue does not grant any access not already available. It is a problem that on unloading a specific kernel module some memory is leaked, but loading kernel modules is a privileged operation. A user could also write a kernel module to consume any amount of memory they like and load that replicating the effect of this bug | |||||