Windows Layer-2 Bridge Network Driver Denial of Service Vulnerability

Missing release of memory after effective lifetime in Windows Layer-2 Bridge Network Driver allows an unauthorized attacker to deny service over an adjacent network.

Windows Secure Socket Tunneling Protocol (SSTP) Denial of Service Vulnerability

Uncontrolled resource consumption in Windows Secure Socket Tunneling Protocol (SSTP) allows an unauthorized attacker to deny service over a network.

Gss-ntlmssp: gss-ntlmssp: memory leak in ntlm_decode_target_info via duplicated av_pair entries in ntlm challenge

A flaw was found in gss-ntlmssp. A memory leak occurs in the NTLM target-info parser when a crafted NTLM CHALLENGE message contains duplicated string-valued AV_PAIR entries. The parser allocates memory for each string value but does not free the previous allocation when the same AV_PAIR type appears more than once, leaking the earlier allocation. A malicious or man-in-the-middle server can exploit this to cause gradual memory exhaustion on the client during NTLM authentication, leading to a denial of service.

FFmpeg through 9.0.2 VVC Decoder Memory Leak via alloc_frame()

FFmpeg through 9.0.2 contains a memory leak vulnerability in alloc_frame() in libavcodec/vvc/refs.c that leaks SPS and PPS references when frame buffer allocation fails. Attackers can supply a crafted VVC (H.266) stream that repeatedly replaces parameter sets, steadily growing memory use and causing denial of service.

Wazuh Manager 3.0.0 before 4.14.9 Memory Leak DoS via JSON Decoder

Wazuh Manager from 3.0.0 before 4.14.9 contains a memory leak vulnerability in the generic JSON decoder that allows remote attackers to exhaust wazuh-analysisd memory via repeated static fields. Attackers can enroll an agent through passwordless enrollment and send events with duplicate fields such as id, triggering an OOM kill that disables alerting.

Missing release of memory after effective lifetime in the MigTD virtio-serial driver for the Intel(R) TDX Migration Trust Domain (MigTD) within Ring 0: Hypervisor may allow a denial of service. System software adversary with a privileged user combined with a low complexity attack may enable denial of service. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (none) and availability (low) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup

In the Linux kernel, the following vulnerability has been resolved: ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup If acpi_nfit_init() fails after adding the acpi_desc object to the acpi_descs list, that object is never removed from that list because the acpi_nfit_shutdown() devm action is not added for the NFIT device in that case. Next, the acpi_nfit_init() failure causes acpi_nfit_probe() to fail, the acpi_desc object is freed, and a dangling pointer is left behind in the acpi_descs. Any subsequent ACPI Machine Check Exception will trigger nfit_handle_mce() which iterates over acpi_descs and so a use-after-free will occur. Moreover, if acpi_nfit_probe() returns 0 after installing a notify handler for the NFIT device and without allocating the acpi_desc object and setting the NFIT device's driver data pointer, the acpi_desc object will be allocated by acpi_nfit_update_notify() and acpi_nfit_init() will be called to initialize it. Regardless of whether or not acpi_nfit_init() fails in that case, the acpi_nfit_shutdown() devm action is not added for the NFIT device and acpi_desc is never removed from the acpi_descs list. If the acpi_desc object is freed subsequently on driver removal, any subsequent ACPI MCE will lead to a use-after-free like in the previous case. To address the first issue mentioned above, make acpi_nfit_probe() call acpi_nfit_shutdown() directly on acpi_nfit_init() failures and to address the other one, add a remove callback to the driver and make it call acpi_nfit_shutdown(). Also, since it is now possible to pass NULL to acpi_nfit_shutdown() or the acpi_desc object passed to it may not have been initialized, add checks against NULL for acpi_desc and its nvdimm_bus field to that function and make acpi_nfit_unregister() clear the latter after unregistering the NVDIMM bus.

Unbounded HTTP/3 Datagram flow map growth in tokio-quiche

Summary Cloudflare tokio-quiche was found to contain an uncontrolled resource consumption vulnerability in its HTTP/3 DATAGRAM handling. For every previously unseen flow identifier (quarter stream ID) received in a DATAGRAM frame, tokio-quiche creates and retains new, per-flow state. A remote peer can send DATAGRAMs with many distinct identifiers, causing the per-connection flow map and associated channel state to grow without bound. Impact Exploitation can exhaust process memory and cause a denial of service. The vulnerable code is used in both client and server configurations, so either role can be affected by a malicious peer. QUIC DATAGRAM support in tokio-quiche is enabled by default through QuicSettings::enable_dgram; applications can disable it by setting this field to false. The vulnerable HTTP/3 path is reachable only when DATAGRAM support is negotiated with the peer. Core quiche and HTTP/3 deployments without DATAGRAM support are not affected.  Mitigation Disable DATAGRAMs in tokio-quiche’s QuicSettings::enable_dgram. Remediation Upgrade to tokio-quiche version 0.23.0 or later. The fixed code creates flow state only for valid DATAGRAM-capable request streams, which are bounded by QUIC’s stream limits. To tolerate packet reordering, servers retain early DATAGRAMs in a bounded, expiring buffer, while clients discard DATAGRAMs for unknown flows.

FFmpeg through 9.0.2 Memory Leak in libxevd EVC Decoder Wrapper

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.

FFmpeg through 9.0.2 Memory Leak in VC-1 Decoder via vc1_decode_frame()

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.

Memory-mapped thread stack is never unmapped when a thread is aborted by another thread, exhausting kernel virtual address space

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).

FFmpeg through 9.0.2 Memory Leak via libx265 Dolby Vision RPU Payloads

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 Memory Leak via VDPAU Hwaccel Bitstream Buffer Table

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 Memory Leak in VP9 Decoder via vp9_decode_frame

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 Resource Leak in libsvtjpegxs JPEG XS Decoder Wrapper

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 Memory Leak in MJPEG Hwaccel SOF Decoding

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 VAAPI Memory Leak via Abandoned Picture Buffers

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.

Memory leak in the Mbed TLS crypto shim on failed cipher/AEAD operations leads to remotely triggered crypto denial of service

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.

FFmpeg through 9.0.2 Memory Leak via MediaCodec JNI setBuffer

FFmpeg through 9.0.2 contains a memory leak vulnerability in mediaformat_jni_setBuffer() in libavcodec/mediacodec_wrapper.c that never frees buffers wrapped with NewDirectByteBuffer(). Attackers can supply crafted media files with large extradata, leaking native memory on each MediaCodec decoder configuration in Android applications and causing resource exhaustion.

ksmbd: reclaim ended sessions on logoff and expiration

In the Linux kernel, the following vulnerability has been resolved: ksmbd: reclaim ended sessions on logoff and expiration LOGOFF and previous-session replacement leave sessions Expired with a zero credential expiry. Ended sessions can retain their memory and connection slots when no further setup arrives on the owning connection. Unpublish a logged-off session while the request reference keeps its response signing and encryption keys alive. Remove its procfs entry before dropping the table reference so a reader cannot remove its own entry on the last put. Clear proc_entry after removal to avoid removing it twice. Reclaim ended sessions from the global table in the existing expiration worker before it acquires conn_list_lock. Only select Expired sessions with zero credential expiry and no references beyond the table reference. Keep sessions whose Kerberos credentials expired available for reauthentication. Unlink the session from its setup connection and all channel connections, so SMB2 sessions and sessions with only secondary SMB3 channels are covered. The session already holds connection references, and sessions_table_lock prevents concurrent channel removal. Queue sessions on a separate disposal list, leaving their hash nodes unhashed, and remove procfs entries and drop table references outside the locks. Keep the pending setup check before allocating a new session so abandoned InProgress sessions can release their slots even at the connection limit. Retain the timeout and reference checks and dispose of those sessions outside the locks. Leave ended Expired sessions to the expiration worker.