Memory leak in pngrutil.c in libpng before 1.2.44, and 1.4.x before 1.4.3, allows remote attackers to cause a denial of service (memory consumption and application crash) via a PNG image containing malformed Physical Scale (aka sCAL) chunks.
An issue has been found in libpng 1.6.34. It is a SEGV in the function png_free_data in png.c, related to the recommended error handling for png_read_image.
A flaw was found in the check_chunk_name() function of pngcheck-2.4.0. An attacker able to pass a malicious file to be processed by pngcheck could cause a temporary denial of service, posing a low risk to application availability.
The png_push_read_zTXt function in pngpread.c in libpng 1.0.x before 1.0.58, 1.2.x before 1.2.48, 1.4.x before 1.4.10, and 1.5.x before 1.5.10 allows remote attackers to cause a denial of service (out-of-bounds read) via a large avail_in field value in a PNG image.
The png_err function in pngerror.c in libpng 1.0.x before 1.0.55, 1.2.x before 1.2.45, 1.4.x before 1.4.8, and 1.5.x before 1.5.4 makes a function call using a NULL pointer argument instead of an empty-string argument, which allows remote attackers to cause a denial of service (application crash) via a crafted PNG image.
The png_decompress_chunk function in pngrutil.c in libpng 1.0.x before 1.0.53, 1.2.x before 1.2.43, and 1.4.x before 1.4.1 does not properly handle compressed ancillary-chunk data that has a disproportionately large uncompressed representation, which allows remote attackers to cause a denial of service (memory and CPU consumption, and application hang) via a crafted PNG file, as demonstrated by use of the deflate compression method on data composed of many occurrences of the same character, related to a "decompression bomb" attack.
Off-by-one error in ICC profile chunk handling in the png_set_iCCP function in pngset.c in libpng before 1.2.22 beta1 allows remote attackers to cause a denial of service (crash) via a crafted PNG image, due to an incorrect fix for CVE-2007-5266.
Off-by-one error in ICC profile chunk handling in the png_set_iCCP function in pngset.c in libpng before 1.0.29 beta1 and 1.2.x before 1.2.21 beta1 allows remote attackers to cause a denial of service (crash) via a crafted PNG image that prevents a name field from being NULL terminated.
pngrtran.c in libpng before 1.0.29 and 1.2.x before 1.2.21 use (1) logical instead of bitwise operations and (2) incorrect comparisons, which might allow remote attackers to cause a denial of service (crash) via a crafted PNG image.
In libpng 1.6.34, a wrong calculation of row_factor in the png_check_chunk_length function (pngrutil.c) may trigger an integer overflow and resultant divide-by-zero while processing a crafted PNG file, leading to a denial of service.
The png_format_buffer function in pngerror.c in libpng 1.0.x before 1.0.55, 1.2.x before 1.2.45, 1.4.x before 1.4.8, and 1.5.x before 1.5.4 allows remote attackers to cause a denial of service (application crash) via a crafted PNG image that triggers an out-of-bounds read during the copying of error-message data. NOTE: this vulnerability exists because of a CVE-2004-0421 regression. NOTE: this is called an off-by-one error by some sources.
Multiple off-by-one errors in libpng before 1.2.32beta01, and 1.4 before 1.4.0beta34, allow context-dependent attackers to cause a denial of service (crash) or have unspecified other impact via a PNG image with crafted zTXt chunks, related to (1) the png_push_read_zTXt function in pngread.c, and possibly related to (2) pngtest.c.
Buffer Overflow vulnerability in libpng 1.6.43-1.6.46 allows a local attacker to cause a denial of service via png_create_read_struct() function.
Memory leak in the embedded_profile_len function in pngwutil.c in libpng before 1.2.39beta5 allows context-dependent attackers to cause a denial of service (memory leak or segmentation fault) via a JPEG image containing an iCCP chunk with a negative embedded profile length. NOTE: this is due to an incomplete fix for CVE-2006-7244.
rfc822.c in Mutt through 2.0.4 allows remote attackers to cause a denial of service (mailbox unavailability) by sending email messages with sequences of semicolon characters in RFC822 address fields (aka terminators of empty groups). A small email message from the attacker can cause large memory consumption, and the victim may then be unable to see email messages from other persons.
When running with FIPS mode enabled, Mirantis Container Runtime 20.10.8 leaks memory during TLS Handshakes which could be abused to cause a denial of service.
A flaw was found in the src/list.c of tar 1.33 and earlier. This flaw allows an attacker who can submit a crafted input file to tar to cause uncontrolled consumption of memory. The highest threat from this vulnerability is to system availability.
An uncontrolled resource consumption (memory leak) flaw was found in the ZeroMQ client in versions before 4.3.3 in src/pipe.cpp. This issue causes a client that connects to multiple malicious or compromised servers to crash. The highest threat from this vulnerability is to system availability.
An uncontrolled resource consumption (memory leak) flaw was found in ZeroMQ's src/xpub.cpp in versions before 4.3.3. This flaw allows a remote unauthenticated attacker to send crafted PUB messages that consume excessive memory if the CURVE/ZAP authentication is disabled on the server, causing a denial of service. The highest threat from this vulnerability is to system availability.
Bareos is open source software for backup, archiving, and recovery of data for operating systems. When Bareos Director >= 18.2 but prior to 21.1.0, 20.0.6, and 19.2.12 is built and configured for PAM authentication, a failed PAM authentication will leak a small amount of memory. An attacker that is able to use the PAM Console (i.e. by knowing the shared secret or via the WebUI) can flood the Director with failing login attempts which will eventually lead to an out-of-memory condition in which the Director will not work anymore. Bareos Director versions 21.1.0, 20.0.6 and 19.2.12 contain a Bugfix for this problem. Users who are unable to upgrade may disable PAM authentication as a workaround.
In Phoenix Contact FL MGUARD 1102 and 1105 in Versions 1.4.0, 1.4.1 and 1.5.0 the remote logging functionality is impaired by the lack of memory release for data structures from syslog-ng when remote logging is active
In process of C2SoftVorbisDec.cpp, there is a possible resource exhaustion due to a memory leak. This could lead to remote denial of service with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-154302257
There are several memory leaks in the MIFF coder in /coders/miff.c due to improper image depth values, which can be triggered by a specially crafted input file. These leaks could potentially lead to an impact to application availability or cause a denial of service. It was originally reported that the issues were in `AcquireMagickMemory()` because that is where LeakSanitizer detected the leaks, but the patch resolves issues in the MIFF coder, which incorrectly handles data being passed to `AcquireMagickMemory()`. This flaw affects ImageMagick versions prior to 7.0.9-0.
A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the av_dict_set function in dict.c.
A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the avpriv_float_dsp_allocl function in libavutil/float_dsp.c.
A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak at the fifo_alloc_common function in libavutil/fifo.c.
Memory leak in the sgpd_parse_entry function in MP4Box in gpac 0.8.0 allows attackers to cause a denial of service (DoS) via a crafted input.
A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the av_buffersrc_add_frame_flags function in buffersrc.
A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the url_open_dyn_buf_internal function in libavformat/aviobuf.c.
Memory leak in the senc_Parse function in MP4Box in gpac 0.8.0 allows attackers to cause a denial of service (DoS) via a crafted input.
A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the filter_frame function in vf_tile.c.
A Denial of Service vulnerability exists in FFmpeg 4.2 idue to a memory leak in the v_frame_alloc function in frame.c.
An issue was discovered in GNU LibreDWG 0.10. Crafted input will lead to an memory leak in dwg_decode_eed ../../src/decode.c:3638.
A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in the inavi_add_ientry function.
A Denial of Service vulnerability exists in FFmpeg 4.2 due to a memory leak in avcodec_alloc_context3 at options.c.
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.
A memory leakage flaw exists in the class PerimeterGenerator of Slic3r libslic3r 1.3.0 and Master Commit b1a5500. Specially crafted stl files can exhaust available memory. An attacker can provide malicious files to trigger this vulnerability.
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.
A memory leak was discovered in matio 1.5.21 and earlier in Mat_VarReadNextInfo5() in mat5.c via a crafted file. This issue can potentially result in DoS.
Jsish v3.5.0 was discovered to contain a memory leak via linenoise at src/linenoise.c.
An issue was discovered in GNU Recutils 1.8. There is a memory leak in rec_buf_new in rec-buf.c when called from rec_parse_rset in rec-parser.c in librec.a.
An exploitable vulnerability exists in the grsecurity PaX patch for the function read_kmem, in PaX from version pax-linux-4.9.8-test1 to 4.9.24-test7, grsecurity official from version grsecurity-3.1-4.9.8-201702060653 to grsecurity-3.1-4.9.24-201704252333, grsecurity unofficial from version v4.9.25-unofficialgrsec to v4.9.74-unofficialgrsec. PaX adds a temp buffer to the read_kmem function, which is never freed when an invalid address is supplied. This results in a memory leakage that can lead to a crash of the system. An attacker needs to induce a read to /dev/kmem using an invalid address to exploit this vulnerability.
An issue was discovered in GPAC version 0.5.2 and 0.9.0-development-20191109. There are memory leaks in metx_New in isomedia/box_code_base.c and abst_Read in isomedia/box_code_adobe.c.
A memory leak was discovered in Mat_VarCalloc in mat.c in matio 1.5.17 because SafeMulDims does not consider the rank==0 case.
Some ZTE products have a DoS vulnerability. Due to the improper handling of memory release in some specific scenarios, a remote attacker can trigger the vulnerability by performing a series of operations, resulting in memory leak, which may eventually lead to device denial of service. This affects: ZXR10 9904, ZXR10 9908, ZXR10 9916, ZXR10 9904-S, ZXR10 9908-S; all versions up to V1.01.10.B12.
ImageMagick 7.0.8-35 has a memory leak in coders/dot.c, as demonstrated by AcquireMagickMemory in MagickCore/memory.c.
A vulnerability in ICMP Version 6 (ICMPv6) processing in Cisco NX-OS Software could allow an unauthenticated, remote attacker to cause a slow system memory leak, which over time could lead to a denial of service (DoS) condition. This vulnerability is due to improper error handling when an IPv6-configured interface receives a specific type of ICMPv6 packet. An attacker could exploit this vulnerability by sending a sustained rate of crafted ICMPv6 packets to a local IPv6 address on a targeted device. A successful exploit could allow the attacker to cause a system memory leak in the ICMPv6 process on the device. As a result, the ICMPv6 process could run out of system memory and stop processing traffic. The device could then drop all ICMPv6 packets, causing traffic instability on the device. Restoring device functionality would require a device reboot.
ImageMagick before 7.0.8-50 has a memory leak vulnerability in the function ReadVIFFImage in coders/viff.c.
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 in AcquireMagickMemory because of an AnnotateImage error.