Vulnerabilities (CVE)

An issue was discovered in the Linux kernel before 5.0.1. There is a memory leak in register_queue_kobjects() in net/core/net-sysfs.c, which will cause denial of service.

In the Linux kernel before 5.1.13, there is a memory leak in drivers/scsi/libsas/sas_expander.c when SAS expander discovery fails. This will cause a BUG and denial of service.

RIOT through 2019.07 contains a memory leak in the TCP implementation (gnrc_tcp), allowing an attacker to consume all memory available for network packets and thus effectively stopping all network threads from working. This is related to _receive in sys/net/gnrc/transport_layer/tcp/gnrc_tcp_eventloop.c upon receiving an ACK before a SYN.

A flaw was found in all dpdk version 17.x.x before 17.11.8, 16.x.x before 16.11.10, 18.x.x before 18.11.4 and 19.x.x before 19.08.1 where a malicious master, or a container with access to vhost_user socket, can send specially crafted VRING_SET_NUM messages, resulting in a memory leak including file descriptors. This flaw could lead to a denial of service condition.

Uncontrolled resource consumption in EDK II may allow an unauthenticated user to potentially enable denial of service via network access.

ImageMagick 7.0.8-50 Q16 has memory leaks at AcquireMagickMemory because of a wand/mogrify.c error.

ImageMagick 7.0.8-50 Q16 has memory leaks at AcquireMagickMemory because of an error in MagickWand/mogrify.c.

ImageMagick 7.0.8-50 Q16 has memory leaks at AcquireMagickMemory because of mishandling the NoSuchImage error in CLIListOperatorImages in MagickWand/operation.c.

ImageMagick 7.0.8-50 Q16 has memory leaks in AcquireMagickMemory because of an AnnotateImage error.

ImageMagick 7.0.8-50 Q16 has direct memory leaks in AcquireMagickMemory because of an error in CLIListOperatorImages in MagickWand/operation.c for a NULL value.

ImageMagick before 7.0.8-50 has a memory leak vulnerability in the function ReadPSImage in coders/ps.c.

ImageMagick before 7.0.8-50 has a memory leak vulnerability in the function ReadVIFFImage in coders/viff.c.

ImageMagick before 7.0.8-50 has a memory leak vulnerability in the function ReadBMPImage in coders/bmp.c.

ImageMagick 7.0.8-34 has a memory leak in the ReadPCLImage function in coders/pcl.c.

ImageMagick 7.0.8-34 has a memory leak vulnerability in the WriteDPXImage function in coders/dpx.c.

An issue was discovered in con_insert_unipair in drivers/tty/vt/consolemap.c in the Linux kernel through 5.1.5. There is a memory leak in a certain case of an ENOMEM outcome of kmalloc. NOTE: This id is disputed as not being an issue

Wind River VxWorks 6.5, 6.6, 6.7, 6.8, 6.9.3 and 6.9.4 has a Memory Leak in the IGMPv3 client component. There is an IPNET security vulnerability: IGMP Information leak via IGMPv3 specific membership report.

A memory leak in archive_read_format_zip_cleanup in archive_read_support_format_zip.c in libarchive 3.3.4-dev allows remote attackers to cause a denial of service via a crafted ZIP file because of a HAVE_LZMA_H typo. NOTE: this only affects users who downloaded the development code from GitHub. Users of the product's official releases are unaffected.

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.

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.

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, ... 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

Show More

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.

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.

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).

GPAC 0.7.1 has a memory leak in dinf_Read in isomedia/box_code_base.c.

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).

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 al ... 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.

Show More

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

K7TSMngr.exe in K7Computing K7AntiVirus Premium 15.1.0.53 has a Memory Leak.

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, CV ... 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.

Show More

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, CV ... 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.

Show More

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.

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.

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.

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).

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.

In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix potential memory leak in otx2_init_tc() In otx2_init_tc(), if rhashtable_init() failed, it does not free tc->tc_entries_bitmap which is allocated in otx2_tc_alloc_ent_bitmap().

In the Linux kernel, the following vulnerability has been resolved: gpiolib: fix memory leak in gpiochip_setup_dev() Here is a backtrace report about memory leak detected in gpiochip_setup_dev(): unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloc_trace device_add device_private_init at drivers/base/core.c:3361 (inlined by) device_add at drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_re ... In the Linux kernel, the following vulnerability has been resolved: gpiolib: fix memory leak in gpiochip_setup_dev() Here is a backtrace report about memory leak detected in gpiochip_setup_dev(): unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloc_trace device_add device_private_init at drivers/base/core.c:3361 (inlined by) device_add at drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_key gcdev_register() & gcdev_unregister() would call device_add() & device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device. However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del(). Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path. Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree(). While at it, fix another subtle issue, i.e. when gc->ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It's not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev->descs variable.

Show More

In the Linux kernel, the following vulnerability has been resolved: Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send() There is a kmemleak when test the raydium_i2c_ts with bpf mock device: unreferenced object 0xffff88812d3675a0 (size 8): comm "python3", pid 349, jiffies 4294741067 (age 95.695s) hex dump (first 8 bytes): 11 0e 10 c0 01 00 04 00 ........ backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] ... In the Linux kernel, the following vulnerability has been resolved: Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send() There is a kmemleak when test the raydium_i2c_ts with bpf mock device: unreferenced object 0xffff88812d3675a0 (size 8): comm "python3", pid 349, jiffies 4294741067 (age 95.695s) hex dump (first 8 bytes): 11 0e 10 c0 01 00 04 00 ........ backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000006e631aee>] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] driver_probe_device+0x49/0x120 [<00000000264fe082>] __device_attach_driver+0xf7/0x150 [<00000000f919423c>] bus_for_each_drv+0x114/0x180 [<00000000e067feca>] __device_attach+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 unreferenced object 0xffff88812d3675c8 (size 8): comm "python3", pid 349, jiffies 4294741070 (age 95.692s) hex dump (first 8 bytes): 22 00 36 2d 81 88 ff ff ".6-.... backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000001d5c9620>] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] driver_probe_device+0x49/0x120 [<00000000264fe082>] __device_attach_driver+0xf7/0x150 [<00000000f919423c>] bus_for_each_drv+0x114/0x180 [<00000000e067feca>] __device_attach+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 After BANK_SWITCH command from i2c BUS, no matter success or error happened, the tx_buf should be freed.

Show More

In the Linux kernel, the following vulnerability has been resolved: can: can327: can327_feed_frame_to_netdev(): fix potential skb leak when netdev is down In can327_feed_frame_to_netdev(), it did not free the skb when netdev is down, and all callers of can327_feed_frame_to_netdev() did not free allocated skb too. That would trigger skb leak. Fix it by adding kfree_skb() in can327_feed_frame_to_netdev() when netdev is down. Not tested, just compiled.