| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Inefficient algorithmic complexity in .NET allows an unauthorized attacker to deny service over a network. |
| An integer overflow in the MessagePack\BufferUnpacker component of rybakit/msgpack versions prior to 0.11.0 allows attackers to cause a denial of service via crafted MessagePack input when the application runs on 32-bit PHP |
| Furl versions before 3.16 for Perl allow memory exhaustion via unbounded decompression of HTTP responses.
Furl inflates a response body sent with a gzip, x-gzip or deflate Content-Encoding and appends the output to the response string with no size limit. It does this whether or not the request asked for compression, and no option caps the decompressed size. Responses read with write_file or write_code are streamed rather than held in memory.
A malicious server, or an attacker on a plain HTTP connection, can send a small compressed response that expands to exhaust the client's memory and end the process. |
| FFmpeg through 9.0.2 contains a memory leak vulnerability in libxevd_receive_frame() in libavcodec/libxevd.c that fails to free pkt_au when an access unit produces no picture. Attackers can supply a crafted EVC stream with many access units containing only parameter sets or non-frame NAL units to exhaust memory in the decoding application. |
| Rack is a modular Ruby web server interface. Prior to 2.2.25, 3.1.23, and 3.2.8, Rack::Multipart::Parser can retain parsed data in its internal StringScanner buffer when reads end inside or immediately after multipart headers. An unauthenticated attacker can align many small parts with rack.multipart.buffer_size boundaries so the buffer grows with the request despite per-field, header, and preamble limits, causing a worker to exhaust memory. The attack requires only a well-formed multipart body and affects applications that parse multipart requests. This issue is fixed in versions 2.2.25, 3.1.23, and 3.2.8. |
| FFmpeg through 9.0.2 contains a memory leak vulnerability in vc1_decode_frame() in libavcodec/vc1dec.c that leaks slice buffers when init_get_bits8() fails. Attackers can supply crafted files with repeated oversized VC-1 slices exceeding the bit reader limit to exhaust memory of decoding applications. |
| When CONFIG_THREAD_STACK_MEM_MAPPED is enabled, each thread stack is mapped into the kernel virtual address space with a guard page on either side, and the mapping is released during abort cleanup. k_thread_abort_cleanup() in kernel/thread.c has two paths: a deferred one for self-abort, which stashes the mapping in thread_cleanup_stack_addr/thread_cleanup_stack_sz, and an immediate one for a thread aborted by some other thread. The immediate path called do_thread_cleanup(), which ignored its thread argument and only ever unmapped the stashed address — a value populated exclusively by the self-abort path. The mapped stack of a thread aborted by another thread was therefore never unmapped.
Every k_thread_abort() of a non-current thread leaks the thread's stack region plus its two guard pages from the kernel virtual address space. Threads that end by returning from their entry function take the working self-abort path, so the leak is specific to explicit cancellation — k_thread_abort(), pthread_cancel(), osThreadTerminate(), or the kernel thread kill shell command. Both k_thread_create() and k_thread_abort() are system calls, so with CONFIG_USERSPACE an unprivileged user-mode thread that has been granted a thread object and a user-capable stack object can drive the leak from user mode, consuming a kernel-side resource it cannot otherwise touch.
With CONFIG_KERNEL_VM_SIZE defaulting to 8 MB, a few hundred create/abort cycles exhaust the runtime mapping region. k_mem_map_phys_guard() then returns NULL, and map_thread_stack() guards that only with __ASSERT_NO_MSG(), which is compiled out of production builds; thread creation proceeds to write through a NULL-derived stack base and faults in kernel mode. The impact is a persistent denial of service — a kernel fatal error requiring a reboot — with no memory disclosure or corruption, and it is limited to configurations where memory-mapped thread stacks are enabled (x86 targets with X86_MMU and demand paging disabled, where the option is implied by default). |
| A security flaw has been discovered in chenyme grok2api up to 3.1.6. Affected by this vulnerability is the function proxyVoiceWebSocket of the file backend/internal/transport/http/inference/voice_ws_handler.go of the component WebSocket Proxy. The manipulation results in resource consumption. The attack may be launched remotely. Upgrading to version 3.1.7 addresses this issue. The patch is identified as 7ad0f791f0a9eb5a0ddfe38ac4dfcef01e19a6d4. It is suggested to upgrade the affected component. |
| GROBID is machine learning software for extracting information from scholarly documents. Prior to 0.9.1, the unauthenticated /api/modelTraining endpoint calls GrobidRestProcessTraining.trainModel in GrobidRestProcessTraining.java, where each request creates Executors.newFixedThreadPool(1), submits a training task, and leaves the executor running. Repeated requests permanently retain JVM worker threads and can exhaust process or operating-system thread capacity, degrading or stopping request processing. This issue is fixed in version 0.9.1. |
| FFmpeg through 9.0.2 contains a memory leak vulnerability in libavcodec/libx265.c because libx265_encode_frame() never frees the rpu.payload allocated by ff_dovi_rpu_generate(). Attackers can supply crafted Dolby Vision HEVC or AV1 files that leak one RPU allocation per encoded frame during libx265 transcoding, causing unbounded memory growth and denial of service. |
| FFmpeg through 9.0.2 contains a memory leak vulnerability in libavcodec/vdpau.c that allows attackers to exhaust heap memory by aborting pictures before end_frame. Attackers can supply crafted H.264 streams with malformed NAL units that repeatedly abandon pictures, leaking the bitstream_buffers table continuously and causing denial of service. |
| FFmpeg 8.0 through 9.0.2 contains a memory leak vulnerability in the VP9 decoder that allows attackers to exhaust memory because vp9_decode_frame() skips resetting the CBS fragment on error paths. Attackers can supply a crafted VP9 stream with invalid tile sizes decoded with slice threading to leak packet buffers and units, exhausting memory in the decoding application. |
| FFmpeg through 9.0.2 contains a denial of service vulnerability in libavcodec/vorbis_parser.c that re-parses invalid extradata for every packet when valid_extradata remains false. Attackers can supply crafted Ogg or Matroska Vorbis streams with large invalid extradata and many packets to exhaust CPU during demuxing or probing. |
| FFmpeg through 9.0.2 contains a resource leak vulnerability in svt_jpegxs_dec_decode() in libsvtjpegxsdec.c that leaks decoder instances when ff_set_dimensions() rejects frame dimensions. Attackers can supply a crafted JPEG XS stream, for example in MPEG-TS, with oversized headers to repeatedly leak decoder threads and buffers, exhausting memory. |
| FFmpeg through 9.0.2 contains a memory leak vulnerability in ff_mjpeg_decode_sof() in libavcodec/mjpegdec.c, which overwrites the hwaccel_picture_private pointer without freeing it. Attackers can supply crafted MJPEG streams with repeated SOF markers or failing frames to leak hwaccel private data and hardware buffers under VAAPI or NVDEC decoding. |
| FFmpeg through 9.0.2 contains a memory leak vulnerability in libavcodec/vaapi_decode.c that allows attackers to exhaust memory by supplying streams with slice parse errors. Attackers can craft H.264 or other VAAPI-decoded video where later slices fail to parse on every frame, continuously leaking VA parameter and slice buffers plus driver and heap memory. |
| The Mbed TLS crypto shim driver in drivers/crypto/crypto_mbedtls_shim.c drives PSA multipart cipher and AEAD operations. In mbedtls_cbc() and mbedtls_aead(), every error path after a successful psa_cipher_encrypt_setup() / psa_aead_decrypt_setup() returned directly without calling psa_cipher_abort() / psa_aead_abort(). Because the abort is the only thing that reaches mbedtls_cipher_free(), each failed operation permanently leaked the heap-allocated mbedtls_aes_context (roughly 288 bytes) that setup had allocated from Mbed TLS's fixed static heap (_mbedtls_heap[CONFIG_MBEDTLS_HEAP_SIZE], default 512 bytes). With CONFIG_PSA_CRYPTO_PROVIDER_TFM the leaked object is instead a finite secure-partition multipart-operation slot.
The failure is chosen by an unauthenticated attacker. With CONFIG_NET_L2_IEEE802154_SECURITY backed by this driver, ieee802154_decrypt_auth() in subsys/net/l2/ieee802154/ieee802154_security.c invokes cipher_ccm_op() on every received secured frame, with no authentication ahead of the MIC check. A device in radio range can transmit a stream of syntactically valid 802.15.4 frames carrying a bogus MIC; each one makes psa_aead_verify() fail and leaks a block. The CBC path is reachable the same way through the OSDP secure channel, where CONFIG_OSDP_SC_ENABLED selects this shim and osdp_encrypt() / osdp_decrypt() leave out_buf_max unset, so every operation fails inside psa_cipher_update().
Exhausting the Mbed TLS heap — which the default configuration reaches after a couple of failed operations, and any realistic configuration reaches in well under a second of frames — makes all subsequent mbedtls_calloc() calls fail. Every later cryptographic operation in the image then fails permanently, including link-layer security and any TLS/DTLS sharing the same heap, until the device is rebooted. There is no memory corruption or information disclosure: frames with an invalid MIC are still rejected, so the impact is limited to availability.
The fix routes all post-setup failures in mbedtls_cbc() and mbedtls_aead() through a common error: label that calls the matching PSA abort before returning. Setup failures need no change, since the PSA core aborts the operation itself when setup fails. |
| SEPPmail Secure Email Gateway before 15.1.1 processes and writes v1 file-interface upload data before authenticating the caller and without an absolute request-size limit. An unauthenticated remote attacker can occupy workers and consume temporary storage with concurrent or slow requests, causing service unavailability. |
| Vulnerability in the Oracle Solaris product of Oracle Systems (component: Filesystems). The supported version that is affected is 11.4. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle Solaris executes to compromise Oracle Solaris. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Solaris. CVSS 3.1 Base Score 5.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). |
| Vulnerability in the Oracle Solaris product of Oracle Systems (component: Filesystems). The supported version that is affected is 11.4. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle Solaris executes to compromise Oracle Solaris. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Solaris. CVSS 3.1 Base Score 5.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). |
