A vulnerability in the Internet Key Exchange Version 2 (IKEv2) module of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a memory leak or a reload of an affected device that leads to a denial of service (DoS) condition. The vulnerability is due to incorrect processing of certain IKEv2 packets. An attacker could exploit this vulnerability by sending crafted IKEv2 packets to an affected device to be processed. A successful exploit could cause an affected device to continuously consume memory and eventually reload, resulting in a DoS condition. Cisco Bug IDs: CSCvf22394.
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2pdu.c omits a kfree call in certain smb2_handle_negotiate error conditions, aka a memory leak.
A potential memory leak issue was discovered in SDL2 in GLES_CreateTexture() function in SDL_render_gles.c. The vulnerability allows an attacker to cause a denial of service attack. The vulnerability affects SDL2 v2.0.4 and above. SDL-1.x are not affected.
UltraJSON is a fast JSON encoder and decoder written in pure C with bindings for Python 3.7+. Prior to 5.12.1, when ujson.dump() writes to a file-like object and the write operation raises an exception, the serialized JSON string object is not decremented, leaking memory. Each failed write operation leaks the full size of the serialized payload. This vulnerability is fixed in 5.12.1.
An issue was discovered in Prosody before 0.12.6 and 1.0.0 through 13.0.0 before 13.0.5. A Denial of Service can occur via memory exhaustion caused by memory leaks from unauthenticated connections.
In the Linux kernel, the following vulnerability has been resolved: net: ncsi: fix skb leak in error paths Early return paths in NCSI RX and AEN handlers fail to release the received skb, resulting in a memory leak. Specifically, ncsi_aen_handler() returns on invalid AEN packets without consuming the skb. Similarly, ncsi_rcv_rsp() exits early when failing to resolve the NCSI device, response handler, or request, leaving the skb unfreed.
In Softing uaToolkit Embedded before 1.41, a malformed CreateMonitoredItems request may cause a memory leak.
JerryScript Git version 14ff5bf does not sufficiently track and release allocated memory via jerry-core/ecma/operations/ecma-regexp-object.c after RegExp, which causes a memory leak.
open5gs v2.4.11 was discovered to contain a memory leak in the component src/upf/pfcp-path.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted PFCP packet.
open5gs v2.4.11 was discovered to contain a memory leak in the component src/smf/pfcp-path.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted PFCP packet.
Live555 through 1.08 has a memory leak in AC3AudioStreamParser for AC3 files.
open5gs v2.4.11 was discovered to contain a memory leak in the component ngap-handler.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted UE attachment.
DCMTK v3.6.7 was discovered to contain a memory leak via the T_ASC_Association object.
A memory leak exists in the Grassroots DICOM library (GDCM). The bug occurs when parsing malformed DICOM files with non-standard VR types in file meta information. The vulnerability leads to vast memory allocations and resource depletion, triggering a denial-of-service condition. A maliciously crafted file can fill the heap in a single read operation without properly releasing it.
In BIG-IP versions 17.0.x before 17.0.0.1, 16.1.x before 16.1.3.2, 15.1.x before 15.1.7, 14.1.x before 14.1.5.2, and 13.1.x before 13.1.5.1, when a sideband iRule is configured on a virtual server, undisclosed traffic can cause an increase in memory resource utilization.
Missing release of memory after effective lifetime in Windows Internet Key Exchange (IKE) Protocol allows an unauthorized attacker to deny service over a network.
Missing Release of Memory after Effective Lifetime vulnerability in MolotovCherry Android-ImageMagick7.This issue affects Android-ImageMagick7: before 7.1.2-11.
Missing Release of Memory after Effective Lifetime vulnerability in MolotovCherry Android-ImageMagick7.This issue affects Android-ImageMagick7: before 7.1.2-11.
In BIG-IP versions 17.0.x before 17.0.0.1, 16.1.x before 16.1.3.1, 15.1.x before 15.1.6.1, 14.1.x before 14.1.5.1, and 13.1.x before 13.1.5.1, when a SIP profile is configured on a virtual server, undisclosed messages can cause an increase in memory resource utilization.
A resource leak in gw_backend.c in lighttpd 1.4.56 through 1.4.66 could lead to a denial of service (connection-slot exhaustion) after a large amount of anomalous TCP behavior by clients. It is related to RDHUP mishandling in certain HTTP/1.1 chunked situations. Use of mod_fastcgi is, for example, affected. This is fixed in 1.4.67.
In Eclipse Jetty, versions 12.0.0-12.0.31 and 12.1.0-12.0.5, class GzipHandler exposes a vulnerability when a compressed HTTP request, with Content-Encoding: gzip, is processed and the corresponding response is not compressed. This happens because the JDK Inflater is allocated for decompressing the request, but it is not released because the release mechanism is tied to the compressed response. In this case, since the response is not compressed, the release mechanism does not trigger, causing the leak.
UltraJSON is a fast JSON encoder and decoder written in pure C with bindings for Python 3.7+. Versions 5.4.0 through 5.11.0 contain an accumulating memory leak in JSON parsing large (outside of the range [-2^63, 2^64 - 1]) integers. The leaked memory is a copy of the string form of the integer plus an additional NULL byte. The leak occurs irrespective of whether the integer parses successfully or is rejected due to having more than sys.get_int_max_str_digits() digits, meaning that any sized leak per malicious JSON can be achieved provided that there is no limit on the overall size of the payload. Any service that calls ujson.load()/ujson.loads()/ujson.decode() on untrusted inputs is affected and vulnerable to denial of service attacks. This issue has been fixed in version 5.12.0.
When storing unbounded types in a BTreeMap, a node is represented as a linked list of "memory chunks". It was discovered recently that when we deallocate a node, in some cases only the first memory chunk is deallocated, and the rest of the memory chunks remain (incorrectly) allocated, causing a memory leak. In the worst case, depending on how a canister uses the BTreeMap, an adversary could interact with the canister through its API and trigger interactions with the map that keep consuming memory due to the memory leak. This could potentially lead to using an excessive amount of memory, or even running out of memory. This issue has been fixed in #212 https://github.com/dfinity/stable-structures/pull/212 by changing the logic for deallocating nodes to ensure that all of a node's memory chunks are deallocated and users are asked to upgrade to version 0.6.4.. Tests have been added to prevent regressions of this nature moving forward. Note: Users of stable-structure < 0.6.0 are not affected. Users who are not storing unbounded types in BTreeMap are not affected and do not need to upgrade. Otherwise, an upgrade to version 0.6.4 is necessary.
An issue was discovered in the sized-chunks crate through 0.6.2 for Rust. In the Chunk implementation, clone can have a memory-safety issue upon a panic.
A specially crafted domain can be used to cause a memory leak in a BIND resolver simply by querying this domain. This issue affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1. BIND 9 versions 9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-S1 are NOT affected.
A vulnerability has been identified in APOGEE MBC (PPC) (BACnet) (All versions), APOGEE MBC (PPC) (P2 Ethernet) (All versions), APOGEE MEC (PPC) (BACnet) (All versions), APOGEE MEC (PPC) (P2 Ethernet) (All versions), APOGEE PXC Compact (BACnet) (All versions < V3.5.7), APOGEE PXC Compact (P2 Ethernet) (All versions < V2.8.21), APOGEE PXC Modular (BACnet) (All versions < V3.5.7), APOGEE PXC Modular (P2 Ethernet) (All versions < V2.8.21), Desigo PXC00-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC00-U (All versions >= V2.3 < V6.30.37), Desigo PXC001-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC100-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC12-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC128-U (All versions >= V2.3 < V6.30.37), Desigo PXC200-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC22-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC22.1-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC36.1-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC50-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC64-U (All versions >= V2.3 < V6.30.37), Desigo PXM20-E (All versions >= V2.3 < V6.30.37), Nucleus NET for Nucleus PLUS V1 (All versions < V5.2a), Nucleus NET for Nucleus PLUS V2 (All versions < V5.4), Nucleus ReadyStart V3 V2012 (All versions < V2012.08.1), Nucleus ReadyStart V3 V2017 (All versions < V2017.02.4), Nucleus Source Code (All versions including affected FTP server), TALON TC Compact (BACnet) (All versions < V3.5.7), TALON TC Modular (BACnet) (All versions < V3.5.7). The FTP server does not properly release memory resources that were reserved for incomplete connection attempts by FTP clients. This could allow a remote attacker to generate a denial of service condition on devices that incorporate a vulnerable version of the FTP server.
The MPTCP module has the memory leak vulnerability. Successful exploitation of this vulnerability can cause memory leaks.
By spoofing the target resolver with responses that have a malformed ECDSA signature, an attacker can trigger a small memory leak. It is possible to gradually erode available memory to the point where named crashes for lack of resources.
By spoofing the target resolver with responses that have a malformed EdDSA signature, an attacker can trigger a small memory leak. It is possible to gradually erode available memory to the point where named crashes for lack of resources.
pdf2xml v2.0 was discovered to contain a memory leak in the function TextPage::testLinkedText.
llama.cpp provides LLM inference in C/C++. The unsafe `type` member in the `rpc_tensor` structure can cause `global-buffer-overflow`. This vulnerability may lead to memory data leakage. The vulnerability is fixed in b3561.
The MPTCP module has the memory leak vulnerability. Successful exploitation of this vulnerability can cause memory leaks.
ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, sometimes msl.c fails to update the stack index, so an image is stored in the wrong slot and never freed on error, causing leaks. Versions 7.1.2-15 and 6.9.13-40 contain a patch.
ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 7.1.2-15 and 6.9.13-40, in `ReadSTEGANOImage()` (`coders/stegano.c`), the `watermark` Image object is not freed on three early-return paths, resulting in a definite memory leak (~13.5KB+ per invocation) that can be exploited for denial of service. Versions 7.1.2-15 and 6.9.13-40 contain a patch.
ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to version 7.1.2-15, a memory leak exists in `coders/ashlar.c`. The `WriteASHLARImage` allocates a structure. However, when an exception is thrown, the allocated memory is not properly released, resulting in a potential memory leak. Version 7.1.2-15 contains a patch.
Missing Release of Memory after Effective Lifetime vulnerability in Is-Daouda is-Engine.This issue affects is-Engine: before 3.3.4.
In versions of Apache CXF before 3.6.4 and 4.0.5 (3.5.x and lower versions are not impacted), a CXF HTTP client conduit may prevent HTTPClient instances from being garbage collected and it is possible that memory consumption will continue to increase, eventually causing the application to run out of memory
In the Linux kernel, the following vulnerability has been resolved: gue: Fix skb memleak with inner IP protocol 0. syzbot reported skb memleak below. [0] The repro generated a GUE packet with its inner protocol 0. gue_udp_recv() returns -guehdr->proto_ctype for "resubmit" in ip_protocol_deliver_rcu(), but this only works with non-zero protocol number. Let's drop such packets. Note that 0 is a valid number (IPv6 Hop-by-Hop Option). I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer: * no error * resubmit HOPOPT [0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm "syz.0.17", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
In the Linux kernel, the following vulnerability has been resolved: net: ti: icssg-prueth: Fix memory leak in XDP_DROP for non-zero-copy mode Page recycling was removed from the XDP_DROP path in emac_run_xdp() to avoid conflicts with AF_XDP zero-copy mode, which uses xsk_buff_free() instead. However, this causes a memory leak when running XDP programs that drop packets in non-zero-copy mode (standard page pool mode). The pages are never returned to the page pool, leading to OOM conditions. Fix this by handling cleanup in the caller, emac_rx_packet(). When emac_run_xdp() returns ICSSG_XDP_CONSUMED for XDP_DROP, the caller now recycles the page back to the page pool. The zero-copy path, emac_rx_packet_zc() already handles cleanup correctly with xsk_buff_free().
On BIG-IP versions 15.0.0-15.0.1.1, 14.1.0-14.1.2, 14.0.0-14.0.1, 13.1.0-13.1.3.1, and 12.1.0-12.1.5, a memory leak in Multicast Forwarding Cache (MFC) handling in tmrouted.
In the Linux kernel, the following vulnerability has been resolved: tls: Purge async_hold in tls_decrypt_async_wait() The async_hold queue pins encrypted input skbs while the AEAD engine references their scatterlist data. Once tls_decrypt_async_wait() returns, every AEAD operation has completed and the engine no longer references those skbs, so they can be freed unconditionally. A subsequent patch adds batch async decryption to tls_sw_read_sock(), introducing a new call site that must drain pending AEAD operations and release held skbs. Move __skb_queue_purge(&ctx->async_hold) into tls_decrypt_async_wait() so the purge is centralized and every caller -- recvmsg's drain path, the -EBUSY fallback in tls_do_decryption(), and the new read_sock batch path -- releases held skbs on synchronization without each site managing the purge independently. This fixes a leak when tls_strp_msg_hold() fails part-way through, after having added some cloned skbs to the async_hold queue. tls_decrypt_sg() will then call tls_decrypt_async_wait() to process all pending decrypts, and drop back to synchronous mode, but tls_sw_recvmsg() only flushes the async_hold queue when one record has been processed in "fully-async" mode, which may not be the case here. [pabeni@redhat.com: added leak comment]
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 vulnerability classified as problematic was found in Linux Kernel. This vulnerability affects the function macvlan_handle_frame of the file drivers/net/macvlan.c of the component skb. The manipulation leads to memory leak. The attack can be initiated remotely. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211024.
A Missing Release of Memory after Effective Lifetime vulnerability in the routing process daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows an attacker to send a malformed BGP Path attribute update which allocates memory used to log the bad path attribute. This memory is not properly freed in all circumstances, leading to a Denial of Service (DoS). Consumed memory can be freed by manually restarting Routing Protocol Daemon (rpd). Memory utilization could be monitored by: user@host> show system memory or show system monitor memory status This issue affects: Junos OS: * All versions before 21.2R3-S8, * from 21.4 before 21.4R3-S8, * from 22.2 before 22.2R3-S4, * from 22.3 before 22.3R3-S3, * from 22.4 before 22.4R3-S3, * from 23.2 before 23.2R2-S1, * from 23.4 before 23.4R1-S2, 23.4R2. Junos OS Evolved: * All versions before 21.2R3-S8-EVO, * from 21.4 before 21.4R3-S8-EVO, * from 22.2 before 22.2R3-S4-EVO, * from 22.3 before 22.3R3-S3-EVO, * from 22.4 before 22.4R3-S3-EVO, * from 23.2 before 23.2R2-S1-EVO, * from 23.4 before 23.4R1-S2-EVO, 23.4R2-EVO.
In Trusted Firmware-M through 1.3.0, cleaning up the memory allocated for a multi-part cryptographic operation (in the event of a failure) can prevent the abort() operation in the associated cryptographic library from freeing internal resources, causing a memory leak.
Redis v7.0 was discovered to contain a memory leak via the component streamGetEdgeID.
A memory leak in the adis_update_scan_mode() function in drivers/iio/imu/adis_buffer.c in the Linux kernel before 5.3.9 allows attackers to cause a denial of service (memory consumption), aka CID-ab612b1daf41.
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.
An attacker can leverage this flaw to gradually erode available memory to the point where named crashes for lack of resources. Upon restart the attacker would have to begin again, but nevertheless there is the potential to deny service.