Total
1928 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-53211 | 1 Linux | 1 Linux Kernel | 2026-07-02 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_meta_bridge: fix stale stack leak via IIFHWADDR register NFT_META_BRI_IIFHWADDR declares its destination register with len = ETH_ALEN (6 bytes), which the register-init tracking rounds up to two 32-bit registers (8 bytes). nft_meta_bridge_get_eval() then does memcpy(dest, br_dev->dev_addr, ETH_ALEN), writing only 6 bytes and leaving the upper 2 bytes of the second register as uninitialised nft_do_chain() stack. A downstream load of that register span leaks those stale bytes to userspace. Zero the second register before the memcpy so the full declared span is written. | |||||
| CVE-2026-53213 | 1 Linux | 1 Linux Kernel | 2026-07-02 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array(). | |||||
| CVE-2026-53222 | 1 Linux | 1 Linux Kernel | 2026-07-02 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ptp: ocp: fix resource freeing order Commit a60fc3294a37 ("ptp: rework ptp_clock_unregister() to disable events") added a call to ptp_disable_all_events() which changes the configuration of pins if they support EXTTS events. In ptp_ocp_detach() pins resources are freed before ptp_clock_unregister() and it leads to use-after-free during driver removal. Fix it by changing the order of free/unregister calls. To avoid irq handler running on the other core while ptp device unregistering, call synchronize_irq() after HW is configured to stop producing irqs and no irqs are in-flight. | |||||
| CVE-2026-53229 | 1 Linux | 1 Linux Kernel | 2026-07-02 | N/A | 7.5 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed. | |||||
| CVE-2026-53227 | 1 Linux | 1 Linux Kernel | 2026-07-02 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the "Fixes" tag, the allocation of the "reply" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming "reply" is allocated before locking: it is freed after unlocking. If "reply" allocation happens after locking the mutex and it fails, "reply" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value. | |||||
| CVE-2026-56364 | 1 Imagemagick | 1 Imagemagick | 2026-07-02 | N/A | 1.9 LOW |
| ImageMagick before 7.1.2-13 contains a memory leak vulnerability in LoadOpenCLDeviceBenchmark() function when parsing malformed OpenCL device profile XML files with unclosed device elements. Attackers with write access to the OpenCL cache directory can place malicious XML files to exhaust memory and cause denial of service. | |||||
| CVE-2026-56365 | 1 Imagemagick | 1 Imagemagick | 2026-07-02 | N/A | 3.7 LOW |
| ImageMagick before 7.1.2-19 contains a memory leak vulnerability in the PNG encoder when writing MNG images. Attackers can trigger the encoder failure condition to exhaust memory resources and cause denial of service. | |||||
| CVE-2026-13474 | 1 Citrix | 2 Netscaler Application Delivery Controller, Netscaler Gateway | 2026-07-02 | N/A | 7.5 HIGH |
| Denial of service via malformed HTTP/2 requests in NetScaler ADC and NetScaler Gateway if HTTP/2 is enabled in HTTP Profile and associated with the virtual server (of type LB, CS, VPN) or the service configured on NetScaler | |||||
| CVE-2026-56371 | 1 Imagemagick | 1 Imagemagick | 2026-07-02 | N/A | 5.3 MEDIUM |
| ImageMagick before 7.1.2-15 and 6.9.13-40 contains a memory leak in coders/txt.c when processing TXT files with texture attributes: the texture object allocated via ReadImage is not released when GetTypeMetrics fails, leaking memory each time a crafted TXT file with a texture attribute is processed. | |||||
| CVE-2026-50254 | 2026-07-01 | N/A | 7.5 HIGH | ||
| An unauthenticated remote attacker can repeatedly send a single crafted connection request to leak memory. Against storescp in its default single-process mode, memory grows quickly and the service is eventually killed, after which it stops accepting connections until an operator restarts it. | |||||
| CVE-2026-35505 | 2026-07-01 | N/A | 7.5 HIGH | ||
| An unauthenticated remote attacker can repeatedly send crafted connection requests to leak memory. In single-process deployments the memory grows until the service is killed and the port stops responding until restart. | |||||
| CVE-2026-53429 | 2026-06-30 | N/A | N/A | ||
| Missing Release of Memory after Effective Lifetime vulnerability in leandrocp mdex and mdex_native allows an attacker who controls a rendered document to cause a denial of service through unbounded native memory exhaustion. The native rendering code permanently leaks memory when rendering a document that contains escaped-tag nodes. The conversion of each %MDEx.EscapedTag{} node into its native representation (From<ExEscapedTag> for NodeValue in the Rust NIF) calls Box::leak on the caller-supplied literal string, which surrenders the backing allocation so that it lives for the entire lifetime of the operating system process and is never freed. Both the byte length of each literal and the number of escaped-tag nodes in a document are attacker-controlled, and there is no size cap, rate limit, or string interning on this path. Every render of a document containing escaped-tag nodes therefore leaks literal_size x node_count bytes that can never be reclaimed, and repeated renders accumulate without bound. Rendering reaches this path through the public MDEx.to_html/1 entry point and any other API that renders a supplied %MDEx.Document{}. Any application that uses mdex (or mdex_native directly) to render documents derived from user-supplied content is affected. Because the leaked memory is never reclaimed for the life of the BEAM process, an attacker can drive resident memory upward without limit until the node exhausts memory and crashes, taking down every process on it. The vulnerable native code originally shipped inside mdex (in native/comrak_nif/src/types/document.rs) and was later extracted into the separate mdex_native package (native/mdex_native_nif/src/types/document.rs), where it remains unpatched. This issue affects mdex from 0.11.0 before 0.12.3, and mdex_native from 0.1.0 before 0.2.3. | |||||
| CVE-2026-13593 | 2026-06-30 | N/A | 6.5 MEDIUM | ||
| CSS::Minifier::XS versions before 0.14 for Perl have a memory leak when the entire document is minified away. The minify function has a memory leak when processing a document containing only characters to be removed, such as comments and whitespace. | |||||
| CVE-2026-56018 | 2026-06-30 | N/A | 7.5 HIGH | ||
| JavaScript::Minifier::XS versions before 0.16 for Perl leak memory on every call to minify(), allowing unbounded memory growth. In JsMinify (XS.xs) the cleanup frees only the NodeSet structures and never the per-token contents buffers allocated in JsSetNodeContents; JsDiscardNode unlinks nodes without freeing their contents. Each token's contents buffer is therefore leaked on every call, and the two early returns taken when the node list is empty leak the whole NodeSet. A long-lived process that minifies repeatedly, such as an asset pipeline or a server-side minifier endpoint, grows in memory without bound until it exhausts available memory and is killed, causing denial of service. | |||||
| CVE-2025-46420 | 2026-06-30 | N/A | 6.5 MEDIUM | ||
| A flaw was found in libsoup. It is vulnerable to memory leaks in the soup_header_parse_quality_list() function when parsing a quality list that contains elements with all zeroes. | |||||
| CVE-2026-56368 | 1 Imagemagick | 1 Imagemagick | 2026-06-26 | N/A | 3.7 LOW |
| ImageMagick before 7.1.2-15 contains a memory leak vulnerability in multiple coders that write raw pixel data where allocated objects are not properly freed. Attackers can trigger this leak by processing specially crafted images, causing memory exhaustion and denial of service. | |||||
| CVE-2024-14027 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: fs/xattr: missing fdput() in fremovexattr error path In the Linux kernel, the fremovexattr() syscall calls fdget() to acquire a file reference but returns early without calling fdput() when strncpy_from_user() fails on the name argument. In multi-threaded processes where fdget() takes the slow path, this permanently leaks one file reference per call, pinning the struct file and associated kernel objects in memory. An unprivileged local user can exploit this to cause kernel memory exhaustion. The issue was inadvertently fixed by commit a71874379ec8 ("xattr: switch to CLASS(fd)"). | |||||
| CVE-2024-6875 | 2026-06-26 | N/A | 6.5 MEDIUM | ||
| A vulnerability was found in the Infinispan component in Red Hat Data Grid. The REST compare API may have a buffer leak and an out of memory error can occur when sending continual requests with large POST data to the REST API. | |||||
| CVE-2026-46103 | 1 Linux | 1 Linux Kernel | 2026-06-25 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: can: ucan: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the control message buffer lifetime so that it is released on driver unbind. | |||||
| CVE-2026-46102 | 1 Linux | 1 Linux Kernel | 2026-06-25 | N/A | 7.5 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: net: strparser: fix skb_head leak in strp_abort_strp() When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized. | |||||