Total
1060 CVE
CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
---|---|---|---|---|---|
CVE-2019-11010 | 3 Debian, Graphicsmagick, Opensuse | 3 Debian Linux, Graphicsmagick, Leap | 2024-11-21 | 4.3 MEDIUM | 6.5 MEDIUM |
In GraphicsMagick 1.4 snapshot-20190322 Q8, there is a memory leak in the function ReadMPCImage of coders/mpc.c, which allows attackers to cause a denial of service via a crafted image file. | |||||
CVE-2019-10649 | 3 Canonical, Debian, Imagemagick | 3 Ubuntu Linux, Debian Linux, Imagemagick | 2024-11-21 | 4.3 MEDIUM | 5.5 MEDIUM |
In ImageMagick 7.0.8-36 Q16, there is a memory leak in the function SVGKeyValuePairs of coders/svg.c, which allows an attacker to cause a denial of service via a crafted image file. | |||||
CVE-2019-10547 | 1 Qualcomm | 64 Apq8009, Apq8009 Firmware, Apq8053 and 61 more | 2024-11-21 | 4.6 MEDIUM | 7.8 HIGH |
When issuing IOCTL calls to ION, Memory leak can occur due to failure in unassign pages under certain conditions in Snapdragon Auto, Snapdragon Compute, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables, Snapdragon Wired Infrastructure and Networking in APQ8009, APQ8053, APQ8096AU, APQ8098, IPQ8074, MDM9206, MDM9207C, MDM9607, MDM9640, MDM9650, MSM8909W, MSM8953, MSM8996AU, Nicobar, QCN7605, QCS605, Rennell, Saipan, SC8180X, SDA660, SDA845, SDM429, SDM429W, SDM439, SDM450, SDM632, SDM710, SDX24, SDX55, SM7150, SM8150, SM8250, SXR2130 | |||||
CVE-2019-1000031 | 1 Article2pdf Project | 1 Article2pdf | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
A disk space or quota exhaustion issue exists in article2pdf_getfile.php in the article2pdf Wordpress plugin 0.24, 0.25, 0.26, 0.27. Visiting PDF generation link but not following the redirect will leave behind a PDF file on disk which will never be deleted by the plug-in. | |||||
CVE-2019-0059 | 1 Juniper | 1 Junos | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
A memory leak vulnerability in the of Juniper Networks Junos OS allows an attacker to cause a Denial of Service (DoS) to the device by sending specific commands from a peered BGP host and having those BGP states delivered to the vulnerable device. This issue affects: Juniper Networks Junos OS: 18.1 versions prior to 18.1R2-S4, 18.1R3-S1; 18.1X75 all versions. Versions before 18.1R1 are not affected. | |||||
CVE-2018-21079 | 1 Google | 1 Android | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
An issue was discovered on Samsung mobile devices with L(5.x), M(6.0), N(7.x), and O(8.0) software. There is a kernel pointer leak in the USB gadget driver. The Samsung ID is SVE-2017-10993 (March 2018). | |||||
CVE-2018-21017 | 1 Gpac | 1 Gpac | 2024-11-21 | 4.3 MEDIUM | 6.5 MEDIUM |
GPAC 0.7.1 has a memory leak in dinf_Read in isomedia/box_code_base.c. | |||||
CVE-2018-17240 | 1 Netwavepr | 4 Indoor Ip Camera, Indoor Ip Camera Firmware, Outdoor Ip Camera and 1 more | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
There is a memory dump vulnerability on Netwave IP camera devices at //proc/kcore that allows an unauthenticated attacker to exfiltrate sensitive information from the network configuration (e.g., username and password). | |||||
CVE-2018-15377 | 1 Cisco | 1 Ios | 2024-11-21 | 7.8 HIGH | 8.6 HIGH |
A vulnerability in the Cisco Network Plug and Play agent, also referred to as the Cisco Open Plug-n-Play agent, of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a memory leak on an affected device. The vulnerability is due to insufficient input validation by the affected software. An attacker could exploit this vulnerability by sending invalid data to the Cisco Network Plug and Play agent on an affected device. A successful exploit could allow the attacker to cause a memory leak on the affected device, which could cause the device to reload. | |||||
CVE-2018-13844 | 1 Htslib | 1 Htslib | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
An issue has been found in HTSlib 1.8. It is a memory leak in fai_read in faidx.c. NOTE: This has been disputed with the assertion that this vulnerability exists in the test harness and HTSlib users would be aware of the need to destruct this object returned by fai_load() in their own code | |||||
CVE-2018-11246 | 1 K7computing | 4 Antivrius, Enterprise Security, Total Security and 1 more | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
K7TSMngr.exe in K7Computing K7AntiVirus Premium 15.1.0.53 has a Memory Leak. | |||||
CVE-2018-0901 | 1 Microsoft | 8 Windows 10, Windows 7, Windows 8.1 and 5 more | 2024-11-21 | 1.9 LOW | 4.7 MEDIUM |
The Windows kernel in Microsoft Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1 and RT 8.1, Windows Server 2012 and R2, Windows 10 Gold, 1511, 1607, 1703, and 1709, Windows Server 2016 and Windows Server, version 1709 allows an information disclosure vulnerability due to the way memory addresses are handled, aka "Windows Kernel Information Disclosure Vulnerability". This CVE is unique from CVE-2018-0811, CVE-2018-0813, CVE-2018-0814, CVE-2018-0894, CVE-2018-0895, CVE-2018-0896, CVE-2018-0897, CVE-2018-0898, CVE-2018-0899, CVE-2018-0900, and CVE-2018-0926. | |||||
CVE-2018-0895 | 1 Microsoft | 8 Windows 10, Windows 7, Windows 8.1 and 5 more | 2024-11-21 | 1.9 LOW | 4.7 MEDIUM |
The Windows kernel in Microsoft Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1 and RT 8.1, Windows Server 2012 and R2, Windows 10 Gold, 1511, 1607, 1703, and 1709, Windows Server 2016 and Windows Server, version 1709 allows an information disclosure vulnerability due to the way memory addresses are handled, aka "Windows Kernel Information Disclosure Vulnerability". This CVE is unique from CVE-2018-0811, CVE-2018-0813, CVE-2018-0814, CVE-2018-0894, CVE-2018-0896, CVE-2018-0897, CVE-2018-0898, CVE-2018-0899, CVE-2018-0900, CVE-2018-0901 and CVE-2018-0926. | |||||
CVE-2018-0891 | 1 Microsoft | 9 Edge, Internet Explorer, Windows 10 and 6 more | 2024-11-21 | 4.3 MEDIUM | 4.3 MEDIUM |
ChakraCore, and Internet Explorer in Microsoft Windows 7 SP1, Windows Server 2008 and R2 SP1, Windows 8.1 and Windows RT 8.1, Windows Server 2012 and R2, and Internet Explorer and Microsoft Edge in Windows 10 Gold, 1511, 1607, 1703, 1709, and Windows Server 2016 allow information disclosure, due to how the scripting engine handles objects in memory, aka "Scripting Engine Information Disclosure Vulnerability". This CVE ID is unique from CVE-2018-0939. | |||||
CVE-2018-0832 | 1 Microsoft | 5 Windows 10, Windows 8.1, Windows Rt 8.1 and 2 more | 2024-11-21 | 1.9 LOW | 4.7 MEDIUM |
The Windows kernel in Windows 8.1 and RT 8.1, Windows Server 2012 R2, Windows 10 Gold, 1511, 1607, 1703 and 1709, Windows Server 2016 and Windows Server, version 1709 allows an information disclosure vulnerability due to how objects in memory are handled, aka "Windows Information Disclosure Vulnerability". This CVE is unique from CVE-2018-0829 and CVE-2018-0830. | |||||
CVE-2017-7654 | 2 Debian, Eclipse | 2 Debian Linux, Mosquitto | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
In Eclipse Mosquitto 1.4.15 and earlier, a Memory Leak vulnerability was found within the Mosquitto Broker. Unauthenticated clients can send crafted CONNECT packets which could cause a denial of service in the Mosquitto Broker. | |||||
CVE-2017-15094 | 1 Powerdns | 1 Recursor | 2024-11-21 | 4.3 MEDIUM | 5.9 MEDIUM |
An issue has been found in the DNSSEC parsing code of PowerDNS Recursor from 4.0.0 up to and including 4.0.6 leading to a memory leak when parsing specially crafted DNSSEC ECDSA keys. These keys are only parsed when validation is enabled by setting dnssec to a value other than off or process-no-validate (default). | |||||
CVE-2024-8376 | 1 Eclipse | 1 Mosquitto | 2024-11-15 | N/A | 7.5 HIGH |
In Eclipse Mosquitto up to version 2.0.18a, an attacker can achieve memory leaking, segmentation fault or heap-use-after-free by sending specific sequences of "CONNECT", "DISCONNECT", "SUBSCRIBE", "UNSUBSCRIBE" and "PUBLISH" packets. | |||||
CVE-2024-50254 | 1 Linux | 1 Linux Kernel | 2024-11-14 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses "kit->nr_bits <= 64" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm "swapper/0", pid 1, jiffies 4294727320 hex dump (first 32 bytes): b0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... f0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): [<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 [<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 [<00000000597124d6>] __alloc.isra.0+0x89/0xb0 [<000000004ebfffcd>] alloc_bulk+0x2af/0x720 [<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 [<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 [<000000008b616eac>] bpf_global_ma_init+0x19/0x30 [<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 [<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 [<00000000b119f72f>] kernel_init+0x20/0x160 [<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 [<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use "!nr_bits || bits >= nr_bits" to check whether the iteration is complete and still use "nr_bits > 64" to indicate whether bits are dynamically allocated. The "!nr_bits" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch. | |||||
CVE-2024-50252 | 1 Linux | 1 Linux Kernel | 2024-11-14 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: <TASK> mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm "ip", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0 |