| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| ImageMagick before 7.1.2-27 contains a memory leak vulnerability in the magick command-line interface when invalid options are provided. Attackers can trigger memory exhaustion by repeatedly supplying malformed command-line arguments to consume system resources. |
| Netty is a network application framework for development of protocol servers and clients. In versions 4.2.0.Final through 4.2.15.Final and 4.1.0.Final through 4.1.135.Final, a remote unauthenticated peer can leak one direct `ByteBuf` per HTTP/2 `DATA` frame in applications that enable HTTP/2 content decompression via `DelegatingDecompressorFrameListener`. When a `DATA` frame is processed for a stream whose decompressor has already been closed, `Http2Decompressor.decompress(...)` calls `decompressor.writeInbound(data.retain())` and does not release the retained buffer on the error path, eventually exhausting direct memory and crashing the JVM. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final. |
| In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: fix zerocopy completion for multi-skb sends
When a large message is fragmented into multiple skbs, the zerocopy
uarg is only allocated and attached to the last skb in the loop.
Non-final skbs carry pinned user pages with no completion tracking,
so the kernel has no way to notify userspace when those pages are safe
to reuse. If the loop breaks early the uarg is never allocated at all,
leaking pinned pages with no completion notification.
Fix this by following the approach used by TCP: allocate the zerocopy
uarg (if not provided by the caller) before the send loop and attach
it to every skb via skb_zcopy_set(), which takes a reference per skb.
Each skb's completion properly decrements the refcount, and the
notification only fires after the last skb is freed.
On failure, if no data was sent, the uarg is cleanly aborted via
net_zcopy_put_abort().
This issue was initially discovered by sashiko while reviewing commit
1cb36e252211 ("vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting")
but was pre-existing. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc
The kernel ASN.1 BER decoder calls action callbacks incrementally as it
walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken
[2] OCTET STRING element, ksmbd_neg_token_alloc() allocates
conn->mechToken immediately via kmemdup_nul(). If a later element in
the same blob is malformed, then the decoder will return nonzero after
the allocation is already live. This could happen if mechListMIC [3]
overrunse the enclosing SEQUENCE.
decode_negotiation_token() then sets conn->use_spnego = false because
both the negTokenInit and negTokenTarg grammars failed. The cleanup at
the bottom of smb2_sess_setup() is gated on use_spnego:
if (conn->use_spnego && conn->mechToken) {
kfree(conn->mechToken);
conn->mechToken = NULL;
}
so the kfree is skipped, causing the mechToken to never be freed.
This codepath is reachable pre-authentication, so untrusted clients can
cause slow memory leaks on a server without even being properly
authenticated.
Fix this up by not checking check for use_spnego, as it's not required,
so the memory will always be properly freed. At the same time, always
free the memory in ksmbd_conn_free() incase some other failure path
forgot to free it. |
| CImg Library is a C++ library for image processing. Prior to version 4.0.0 in `_load_analyze()`, the header_size field is read as an `unsigned int` from the first 4 bytes of an Analyze/NIfTI file and passed directly to `new unsigned char[header_size]` without being bounded against the actual file size. A value up to ~4 GB is accepted. If the subsequent `fread` returns `short` as it will for any malformed file), the function throws a `CImgIOException` and the allocated buffer is never freed. A 6-byte crafted file is sufficient to trigger an allocation of ~1.3 GB per call, with the full allocation leaked on every error path. The issue is reachable via `load_analyze()` and the generic `load()` when the file extension is .hdr, .img, or .nii. Version 4.0.0 fixes the issue. |
| The CONFIG_USERSPACE syscall verifier z_vrfy_k_poll() in kernel/poll.c allocates a kernel-side copy of the user-supplied k_poll_event[] via z_thread_malloc() and then validates each event's object handle. Before this fix, validation used K_OOPS(K_SYSCALL_OBJ(...)) inline inside the loop, which kills the calling thread without freeing events_copy.
A user thread can pass num_events >= 1 with a forged object handle to leak the allocation; because newly spawned user threads inherit the parent's resource_pool (kernel/thread.c), an attacker spawns sacrificial threads to repeat the leak until the shared kernel heap is exhausted. Once depleted, legitimate kernel allocations from that pool (k_queue alloc nodes, k_msgq buffers, future k_poll calls, etc.) fail, causing a system-level denial of service.
The fix replaces each inline K_OOPS with a conditional goto oops_free so the buffer is freed before the thread is killed. Affects Zephyr releases from v1.12.0 (when k_poll was first exposed to user mode) through v4.4.1. |
| The QUIC transport parameters extension handler in s2n-tls incorrectly uses s2n_alloc instead of s2n_realloc to store the peer's transport parameters. When a TLS 1.3 connection goes through a HelloRetryRequest, the handler is called twice on the same connection. On the second call, s2n_alloc zeroes the existing pointer before allocating new memory, causing the first allocation to be leaked.
This can occur during normal QUIC traffic when a client offers a key share group the server does not prefer. An unauthenticated user can amplify the issue by deliberately forcing HelloRetryRequests, causing up to approximately 64 KB of unreachable memory per handshake. Over time, this can lead to increased memory consumption on long-running server processes. The unreachable memory is only reclaimed when the process is restarted.
Only server-side QUIC-enabled deployments are affected. Non-QUIC TLS connections are not affected.
We recommend you upgrade s2n-tls to version v1.7.6 |
| In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix posix_acl leak on SETACL decode failure
nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each
call nfs_stream_decode_acl() twice, first for NFS_ACL and then for
NFS_DFACL. Each successful call transfers ownership of a freshly
allocated posix_acl into argp->acl_access or argp->acl_default. If
the first call succeeds but the second fails, the decoder returns
false and argp->acl_access is left dangling.
ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and
ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle.
Both only call fh_put() and have no knowledge of the ACL fields on
argp. The posix_acl_release() pairs sat at the out: labels inside
nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process()
skips pc_func when pc_decode returns false, so that cleanup is
unreachable on decode failure:
svc_process_common()
pc_decode() /* decode_setaclargs: false */
/* pc_func skipped */
pc_release() /* fh_put only -- ACLs leaked */
The orphaned posix_acl is leaked for the lifetime of the server.
Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(),
which release both argp->acl_access and argp->acl_default in addition
to fh_put(), and wiring them as pc_release for their respective SETACL
procedures. pc_release runs on every path svc_process() takes after
decode, including decode failure, so the posix_acl_release() pairs are
removed from the proc functions' out: labels to keep ownership in one
place. This matches the existing release_getacl() pattern used by
the sibling GETACL procedures. |
| In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix posix_acl leak and ignored error in nfsd4_create_file
nfsd4_create_file() has two bugs in its ACL handling:
The return value of nfsd4_acl_to_attr() is silently discarded. When
the NFSv4-to-POSIX ACL conversion fails (e.g., -EINVAL for
unsupported ACE types), the file is created without any ACL and the
client receives NFS4_OK. This violates RFC 7530/8881 which require
the server to reject unsupported attributes on CREATE.
When start_creating() fails after ACL attributes have been populated
in attrs (either via nfsd4_acl_to_attr or via ownership transfer from
open->op_dpacl/op_pacl), the function jumps to out_write which skips
nfsd_attrs_free(). The posix_acl allocations are leaked. A client
can trigger this repeatedly with OPEN(CREATE), ACL attributes, and an
invalid filename (e.g., longer than NAME_MAX).
Fix both by capturing the nfsd4_acl_to_attr() return value and by
changing the early error paths to jump to out instead of out_write.
Initialize child to ERR_PTR(-EINVAL) so that end_creating() is safe
to call even if start_creating() was never reached. |
| In the Linux kernel, the following vulnerability has been resolved:
nfsd: avoid leaking pre-allocated openowner on unconfirmed retry race
When find_or_alloc_open_stateowner() encounters an unconfirmed owner, it
calls release_openowner() and sets oo = NULL. Control then falls through
past the `if (oo)` guard -- which would have freed any pre-allocated
`new` -- and unconditionally executes `new = alloc_stateowner(...)`. If
`new` was already allocated on a prior iteration, the pointer is
silently overwritten and the previous allocation (slab object + owner
name buffer) is leaked.
This requires a race: two NFSv4.0 OPEN threads with the same owner
string, where a concurrent thread inserts a new unconfirmed owner into
the hash between retry iterations. The window is narrow but repeatable
under adversarial conditions.
Fix by adding `goto retry` after `oo = NULL` so the already-allocated
`new` is reused on the next iteration rather than overwritten. |
| In the Linux kernel, the following vulnerability has been resolved:
irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove
The driver allocates domain generic chips using
irq_alloc_domain_generic_chips() during probe and sets up chained
handlers using irq_set_chained_handler_and_data(). However, on driver
removal, the generic chips are not freed and the chained handlers are
not removed.
The generic chips remain on the global gc_list and may later be accessed by
generic interrupt chip suspend, resume, or shutdown callbacks after the
driver has been removed, potentially resulting in a use-after-free and
kernel crash.
The chained handlers that were installed in probe for peripheral and
syswake interrupts are also left dangling, which can lead to spurious
interrupts accessing freed memory.
Fix these issues by:
- Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the
core code automatically removes generic chips when irq_domain_remove()
is called
- Clearing all chained handlers with NULL in pdc_intc_remove() |
| In the Linux kernel, the following vulnerability has been resolved:
drm/colorop: Fix blob property reference tracking in state lifecycle
The colorop state blob property handling had memory leaks during state
duplication, destruction, and reset operations. The implementation
failed to follow the established pattern from drm_crtc's handling of
DEGAMMA/GAMMA blob properties.
Issues fixed:
- drm_colorop_atomic_destroy_state() was freeing state memory without
releasing the blob reference, causing a leak
- drm_colorop_reset() was directly freeing old state with kfree()
instead of properly destroying it, leaking blob references
- drm_colorop_cleanup() had duplicate blob cleanup code
Changes:
- Add __drm_atomic_helper_colorop_destroy_state() helper to properly
release blob references before freeing state memory
- Update drm_colorop_atomic_destroy_state() to call the helper
- Fix drm_colorop_reset() to use drm_colorop_atomic_destroy_state()
for proper cleanup of old state
- Simplify drm_colorop_cleanup() to use the common destruction path
This matches the well-tested pattern used by drm_crtc since 2016 and
ensures proper reference counting throughout the state lifecycle.
Co-developed by Claude Sonnet 4.5. |
| In the Linux kernel, the following vulnerability has been resolved:
gpio: rockchip: fix generic IRQ chip leak on remove
The driver allocates domain generic chips using
irq_alloc_domain_generic_chips() during probe. However, on driver
remove/teardown, the generic chips are not automatically freed when the
IRQ domain is removed because the domain flags do not include
IRQ_DOMAIN_FLAG_DESTROY_GC.
This causes both the domain generic chips structure and the associated
generic chips to be leaked. Additionally, the generic chips remain on
the global gc_list and may later be visited by generic IRQ chip suspend,
resume, or shutdown callbacks after the GPIO bank has been removed,
potentially resulting in a use-after-free and kernel crash.
Fix the resource leak by explicitly calling
irq_domain_remove_generic_chips() before removing the IRQ domain in
rockchip_gpio_remove(). |
| ImageMagick before 7.1.2-26 (and 6.x before 6.9.13-51) contains a memory leak in the TIFF encoder that occurs when a temporary file cannot be created, resulting in a small memory leak. |
| ImageMagick before 7.1.2-26 and 6.9.13-51 contains a memory leak in the TIFF encoder when an invalid tiff:tile-geometry is specified. Supplying malformed tile geometry parameters causes allocated memory not to be released, which can lead to increased memory consumption. |
| ImageMagick through 7.1.2-18 contains a memory leak vulnerability in the ASHLAR coder when an action fails. Attackers can trigger failed actions to exhaust memory resources and cause denial of service. |
| ImageMagick before 7.1.2-26 and 6.9.13-51 contains a memory leak in color transformation to the log colorspace: when the operation fails, a small amount of memory is not released. |
| ImageMagick before 7.1.2-26 and 6.9.13-51 contains a memory leak in the hough lines operation: when a specific operation fails, a small memory leak occurs. |
| ImageMagick before 7.1.2-26 contains a memory leak vulnerability in the TIFF encoder when memory allocation fails. Attackers can trigger allocation failures during TIFF image processing to cause memory exhaustion and denial of service. |
| ImageMagick before 7.1.2-26 and 6.9.13-51 contains a memory leak in the ICON decoder that occurs when a memory allocation fails. Processing a crafted ICON file that triggers an allocation failure leaks memory, which may lead to a denial of service. |
