When reading a specially crafted JPEG file, metadata-extractor up to 2.16.0 can be made to allocate large amounts of memory that finally leads to an out-of-memory error even for very small inputs. This could be used to mount a denial of service attack against services that use metadata-extractor library.

Helm is a package manager for Charts for Kubernetes. Prior to version 3.18.5, it is possible to craft a JSON Schema file in a manner which could cause Helm to use all available memory and have an out of memory (OOM) termination. This issue has been resolved in Helm 3.18.5. A workaround involves ensuring all Helm charts that are being loaded into Helm do not have any reference of $ref pointing to /dev/zero.

Helm is a tool for managing Charts. A chart archive file can be crafted in a manner where it expands to be significantly larger uncompressed than compressed (e.g., >800x difference). When Helm loads this specially crafted chart, memory can be exhausted causing the application to terminate. This issue has been resolved in Helm v3.17.3.

An issue was discovered in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.32. It is an attempted excessive memory allocation in _bfd_elf_slurp_version_tables in elf.c.

An issue was discovered in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.32. It is an attempted excessive memory allocation in setup_group in elf.c.

An issue was discovered in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.32. It is an attempted excessive memory allocation in elf_read_notes in elf.c.

wasm::WasmBinaryBuilder::readUserSection in wasm-binary.cpp in Binaryen 1.38.22 triggers an attempt at excessive memory allocation, as demonstrated by wasm-merge and wasm-opt.

An issue was discovered in Bento4 1.5.1-628. The AP4_ElstAtom class in Core/Ap4ElstAtom.cpp has an attempted excessive memory allocation related to AP4_Array<AP4_ElstEntry>::EnsureCapacity in Core/Ap4Array.h, as demonstrated by mp42hls.

An issue was discovered in AP4_Array<AP4_CttsTableEntry>::EnsureCapacity in Core/Ap4Array.h in Bento4 1.5.1-627. Crafted MP4 input triggers an attempt at excessive memory allocation, as demonstrated by mp42hls, a related issue to CVE-2018-20095.

An issue was discovered in OpenJPEG 2.3.0. It allows remote attackers to cause a denial of service (attempted excessive memory allocation) in opj_calloc in openjp2/opj_malloc.c, when called from opj_tcd_init_tile in openjp2/tcd.c, as demonstrated by the 64-bit opj_decompress.

An attempted excessive memory allocation was discovered in the function read_long_names in elf_begin.c in libelf in elfutils 0.174. Remote attackers could leverage this vulnerability to cause a denial-of-service via crafted elf input, which leads to an out-of-memory exception. NOTE: The maintainers believe this is not a real issue, but instead a "warning caused by ASAN because the allocation is big. By setting ASAN_OPTIONS=allocator_may_return_null=1 and running the reproducer, nothing happens."

PNGDec commit 8abf6be was discovered to contain a memory allocation problem via asan_malloc_linux.cpp.

An issue was discovered in GNU LibreDWG before 0.93. Crafted input will lead to an attempted excessive memory allocation in dwg_decode_SPLINE_private in dwg.spec.

An issue was discovered in GNU LibreDWG 0.92. Crafted input will lead to an attempted excessive memory allocation in dwg_decode_LWPOLYLINE_private in dwg.spec.

An issue was discovered in GNU LibreDWG 0.92. Crafted input will lead to an attempted excessive memory allocation in dwg_decode_HATCH_private in dwg.spec.

An attempted excessive memory allocation was discovered in Mat_VarRead5 in mat5.c in matio 1.5.17.

An issue was discovered in GNU LibreDWG before 0.93. Crafted input will lead to an attempted excessive memory allocation in decode_3dsolid in dwg.spec.

Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Starting in version 0.3.2 and prior to versions 0.3.8, 0.4.19, and 0.5.6, there is a possibility for denial of service by memory exhaustion in `net-imap`'s response parser. At any time while the client is connected, a malicious server can send can send highly compressed `uid-set` data which is automatically read by the client's receiver thread. The response parser uses `Range#to_a` to convert the `uid-set` data into arrays of integers, with no limitation on the expanded size of the ranges. Versions 0.3.8, 0.4.19, 0.5.6, and higher fix this issue. Additional details for proper configuration of fixed versions and backward compatibility are available in the GitHub Security Advisory.

An issue was discovered in Bento4 v1.2. There is an allocation size request error in /Ap4RtpAtom.cpp.

mp4v2 v2.1.2 was discovered to contain a memory leak via the class MP4BytesProperty.

A vulnerability was found in dnsmasq before version 2.81, where the memory leak allows remote attackers to cause a denial of service (memory consumption) via vectors involving DHCP response creation.

An issue was discovered in GitLab EE affecting all versions starting with 12.3 before 17.7.7, 17.8 prior to 17.8.5, and 17.9 prior to 17.9.2. A vulnerability in certain GitLab instances could allow an attacker to cause a denial of service condition by manipulating specific API inputs.

In libjpeg-turbo 2.0.2, a large amount of memory can be used during processing of an invalid progressive JPEG image containing incorrect width and height values in the image header. NOTE: the vendor's expectation, for use cases in which this memory usage would be a denial of service, is that the application should interpret libjpeg warnings as fatal errors (aborting decompression) and/or set limits on resource consumption or image sizes

A PngChunk::parseChunkContent uncontrolled memory allocation in Exiv2 through 0.27.1 allows an attacker to cause a denial of service (crash due to an std::bad_alloc exception) via a crafted PNG image file.

Apache CXF before 3.3.4 and 3.2.11 does not restrict the number of message attachments present in a given message. This leaves open the possibility of a denial of service type attack, where a malicious user crafts a message containing a very large number of message attachments. From the 3.3.4 and 3.2.11 releases, a default limit of 50 message attachments is enforced. This is configurable via the message property "attachment-max-count".

An issue was discovered in PoDoFo 0.9.6. The PdfPagesTreeCache class in doc/PdfPagesTreeCache.cpp has an attempted excessive memory allocation because nInitialSize is not validated.

In Apache Tika 1.19 to 1.21, a carefully crafted 2003ml or 2006ml file could consume all available SAXParsers in the pool and lead to very long hangs. Apache Tika users should upgrade to 1.22 or later.

A shortcoming in the HMEF package of poi-scratchpad (Apache POI) allows an attacker to cause an Out of Memory exception. This package is used to read TNEF files (Microsoft Outlook and Microsoft Exchange Server). If an application uses poi-scratchpad to parse TNEF files and the application allows untrusted users to supply them, then a carefully crafted file can cause an Out of Memory exception. This issue affects poi-scratchpad version 5.2.0 and prior versions. Users are recommended to upgrade to poi-scratchpad 5.2.1.

In PoDoFo 0.9.5, there is an uncontrolled memory allocation in the PoDoFo::PdfVecObjects::Reserve function (base/PdfVecObjects.h). Remote attackers could leverage this vulnerability to cause a denial of service via a crafted pdf file.

gd_gif_in.c in the GD Graphics Library (aka libgd), as used in PHP before 5.6.33, 7.0.x before 7.0.27, 7.1.x before 7.1.13, and 7.2.x before 7.2.1, has an integer signedness error that leads to an infinite loop via a crafted GIF file, as demonstrated by a call to the imagecreatefromgif or imagecreatefromstring PHP function. This is related to GetCode_ and gdImageCreateFromGifCtx.

By design, BIND is intended to limit the number of TCP clients that can be connected at any given time. The number of allowed connections is a tunable parameter which, if unset, defaults to a conservative value for most servers. Unfortunately, the code which was intended to limit the number of simultaneous connections contained an error which could be exploited to grow the number of simultaneous connections beyond this limit. Versions affected: BIND 9.9.0 -> 9.10.8-P1, 9.11.0 -> 9.11.6, 9.12.0 -> 9.12.4, 9.14.0. BIND 9 Supported Preview Edition versions 9.9.3-S1 -> 9.11.5-S3, and 9.11.5-S5. Versions 9.13.0 -> 9.13.7 of the 9.13 development branch are also affected. Versions prior to BIND 9.9.0 have not been evaluated for vulnerability to CVE-2018-5743.

In PoDoFo 0.9.5, there is an uncontrolled memory allocation in the PdfParser::ReadXRefSubsection function (base/PdfParser.cpp). Remote attackers could leverage this vulnerability to cause a denial-of-service via a crafted pdf file.

In libming 0.4.8, there is an integer signedness error vulnerability (left shift of a negative value) in the readSBits function (util/read.c). Remote attackers can leverage this vulnerability to cause a denial of service via a crafted swf file.

The Exiv2::Jp2Image::readMetadata function in jp2image.cpp in Exiv2 0.26 allows remote attackers to cause a denial of service (excessive memory allocation) via a crafted file.

protobufjs is vulnerable to ReDoS when parsing crafted invalid .proto files.

iText v7.1.17, up to (exluding)": 7.1.18 and 7.2.2 was discovered to contain an out-of-memory error via the component readStreamBytesRaw, which allows attackers to cause a Denial of Service (DoS) via a crafted PDF file.

An issue was discovered in Bento4 1.5.1-627. The AP4_StcoAtom class in Core/Ap4StcoAtom.cpp has an attempted excessive memory allocation when called from AP4_AtomFactory::CreateAtomFromStream in Core/Ap4AtomFactory.cpp, as demonstrated by mp42hls.

An issue was discovered in EnsureCapacity in Core/Ap4Array.h in Bento4 1.5.1-627. Crafted MP4 input triggers an attempt at excessive memory allocation, as demonstrated by mp42hls.

There is an excessive memory allocation issue in the functions ReadBMPImage of coders/bmp.c and ReadDIBImage of coders/dib.c in ImageMagick 7.0.8-11, which allows remote attackers to cause a denial of service via a crafted image file.

The Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.30, allows remote attackers to cause a denial of service (excessive memory allocation and application crash) via a crafted ELF file, as demonstrated by _bfd_elf_parse_attributes in elf-attrs.c and bfd_malloc in libbfd.c. This can occur during execution of nm.

An issue was discovered in Free Lossless Image Format (FLIF) 0.3. The Plane function in image/image.hpp allows remote attackers to cause a denial of service (attempted excessive memory allocation) via a crafted file.

Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable.

GNU Debugger (GDB) 8.0 and earlier fails to detect a negative length field in a DWARF section. A malformed section in an ELF binary or a core file can cause GDB to repeatedly allocate memory until a process limit is reached. This can, for example, impede efforts to analyze malware with GDB.

GNU Binutils 2.28 allows remote attackers to cause a denial of service (memory consumption) via a crafted ELF file with many program headers, related to the get_program_headers function in readelf.c.

The GetHintFormat function in GPAC 1.0.1 allows attackers to cause a denial of service via a crafted file in the MP4Box command.

A memory allocation vulnerability was found in netpbm before 10.61. A maliciously crafted SVG file could cause the application to crash.

There's a flaw in OpenEXR's Scanline API functionality in versions before 3.0.0-beta. An attacker who is able to submit a crafted file to be processed by OpenEXR could trigger excessive consumption of memory, resulting in an impact to system availability.

An issue was discovered in GraphicsMagick 1.3.26. An allocation failure vulnerability was found in the function ReadOnePNGImage in coders/png.c, which allows attackers to cause a denial of service via a crafted file that triggers an attempt at a large png_pixels array allocation.

The xz_head function in xzlib.c in libxml2 before 2.9.6 allows remote attackers to cause a denial of service (memory consumption) via a crafted LZMA file, because the decoder functionality does not restrict memory usage to what is required for a legitimate file.

An issue was discovered in GraphicsMagick 1.3.26. An allocation failure vulnerability was found in the function ReadTIFFImage in coders/tiff.c, which allows attackers to cause a denial of service via a crafted file, because file size is not properly used to restrict scanline, strip, and tile allocations.