| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
media: sun4i-csi: Return queued buffers on start_streaming() failure
The vb2 framework hands buffers to the driver via buf_queue() before
calling start_streaming(). If start_streaming() returns an error
without first returning those buffers via vb2_buffer_done(),
vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued
buffers leak.
sun4i_csi_start_streaming() returned -EINVAL when no matching CSI
format could be found, before any setup (scratch buffer allocation,
pipeline start) had been performed. The remaining error paths already
converge on the err_clear_dma_queue label, which calls
return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump
to that label directly: the intermediate err_disable_device /
err_disable_pipeline / err_free_scratch_buffer labels are skipped,
which is correct because nothing they would undo has happened yet.
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure"). |
| In the Linux kernel, the following vulnerability has been resolved:
fscrypt: Add missing superblock check in find_or_insert_direct_key()
The legacy 'fscrypt_direct_keys' table caches master keys that are used
by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY.
It's just a global table for all filesystems (since the keys can be
provided by the legacy process-subscribed keyrings mechanism, which
makes it difficult to reuse super_block::s_master_keys).
The entries in it ('struct fscrypt_direct_key') do contain a super_block
pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when
the last inode that references the key is evicted.
However, when finding the fscrypt_direct_key for an inode, we weren't
actually comparing the super_block pointer. As a result, inodes with
different super_blocks could point to the same fscrypt_direct_key. That
could extend the lifetime of a fscrypt_direct_key beyond the
super_block it points to, causing a use-after-free later.
Fix this by creating distinct fscrypt_direct_key structs for distinct
super_block structs.
Note that this problem doesn't exist in the v2 policy equivalent
("per-mode keys"), since the data structures there are per super_block. |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user who is authorized to manage maintenance windows could submit a specially crafted, malformed payload that causes the Kibana process to consume excessive resources. Kibana becomes unresponsive for all users and does not recover without manual intervention. |
| A flaw in Elasticsearch allows an authenticated user holding only read privileges to submit a small search request containing a crafted user-supplied input. Processing that input causes a specific internal component to allocate memory without any upper bound, and the allocation occurs outside the scope of the existing memory accounting controls that were intended to constrain it. The resulting out-of-memory condition is fatal and terminates the affected node process, causing a denial of service. |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). A user-supplied list of document fields accepted by the Kibana Playground for RAG feature was neither bounded in length nor de-duplicated before it was used to assemble the response for each matching document. A single crafted request could therefore make Kibana build a response far larger than the data it was derived from, and the resulting processing and memory pressure exhausts the resources of the Kibana instance. |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). A specially crafted request submitted by an authenticated user with minimal privileges to a validation capability of the Observability log analysis feature causes Kibana to perform an unbounded amount of concurrent work. This can exhaust the memory available to the Kibana process and make Kibana unavailable to all users until it is restarted. The severity of the outcome depends on the resources allocated to the deployment; on well-provisioned deployments a single request may cause degraded performance and elevated memory pressure rather than a full outage, but the request is inexpensive to repeat. |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). A specially crafted, malformed payload submitted to a Kibana visualization feature by an authenticated user holding only low-privileged access is not correctly validated before use. Processing the request causes unbounded memory growth in the Kibana process, which is terminated by the host once available memory is exhausted. Kibana then becomes unavailable to all users until the service is restarted. |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user with read-only privileges to the alerting feature could submit a specially crafted, malformed payload that causes the Kibana process to consume excessive resources. A single request is sufficient to leave Kibana unable to serve requests for all users until the process is restarted. |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). A query expression accepted by a connector reporting operation was processed without any limit on its size, and an oversized expression caused the Kibana process to spend an unbounded amount of time evaluating it. An authenticated user with read-only privileges was able to send a single request that left Kibana unable to serve any user until the process was restarted. |
| Gitea SSH Key Parser Denial of Service |
| fast-xml-parser allows users to process XML from JS object without C/C++ based libraries or callbacks. From 5.9.3 until 5.10.1, src/xmlparser/OrderedObjParser.js processes multiple DOCTYPE declarations within a single XML document and passes each declaration's entities through addInputEntities(). addInputEntities() resets maxTotalExpansions and maxExpandedLength every time it is called, allowing additional DOCTYPE declarations to repeatedly reset the configured entity-expansion limits during one parse operation. A crafted XML document can then cause excessive CPU use, event-loop blocking, memory exhaustion, and process termination. This issue is fixed in version 5.10.1. |
| Denial of Service via Unbounded io.ReadAll in NPM Package Tag Endpoint |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote attacker to cause a denial of service due to unbounded resource allocation. |
| Netty is an asynchronous, event-driven network application framework. Prior to 4.1.136.Final and 4.2.16.Final, io.netty.handler.codec.dns.AbstractDnsRecord, io.netty.handler.codec.dns.DefaultDnsRecordDecoder.decodeRecord(), and io.netty.handler.codec.dns.DnsCodecUtil.decompressDomainName() failed to release retained or newly allocated ByteBuf objects when IDN.toASCII() or encodeDomainName() rejected a malformed domain name, allowing unauthenticated remote DNS packets to leak direct memory incrementally until denial of service. 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:
batman-adv: frag: disallow unicast fragment in fragment
batadv_frag_skb_buffer() is called by batadv_batman_skb_recv() when a
BATADV_UNICAST_FRAG packet is received. Once all fragments are collected
and the packet is reassembled, batadv_recv_frag_packet() calls
batadv_batman_skb_recv() again to process the defragmented payload.
A malicious sender can craft a BATADV_UNICAST_FRAG packet whose reassembled
payload is itself a BATADV_UNICAST_FRAG packet (matryoshka-style nesting).
Each nesting level recurses through batadv_batman_skb_recv() without bound,
growing the kernel stack until it is exhausted.
Since refragmentation or fragments in fragments are not actually allowed,
discard all packets which are still BATADV_UNICAST_FRAG packets after the
defragmentation process. |
| Klever-Go is the Go implementation of the Klever blockchain protocol. In versions prior to 1.7.18, the account-data trie syncers are vulnerable to a resource-exhaustion flaw that leaks bounded throttler slots on error paths. In syncDataTrie() (in both userAccountsSyncer.go and kappAccountsSyncer.go), StartProcessing() reserves a slot from the NumGoRoutinesThrottler, but the corresponding EndProcessing() is only called on the success path and on the duplicate-root early return. As a result, any error from trie.NewTrie(), trie.NewTrieSyncer(), or trieSyncer.StartSyncing() (including the network-dependent timeout path) permanently consumes one slot for the lifetime of the throttler. An attacker who can repeatedly cause trie-node sync failures or timeouts during bootstrap can exhaust the bounded throttler, after which further account-data trie syncs stop making progress and SyncAccounts() returns a timeout. Because epoch bootstrap in syncUserAccountsState() and syncKappAccountsState() aborts on any such error, this causes bootstrap to fail, a core availability issue affecting fresh, restarting, or resyncing nodes and validators. This issue is fixed in version 1.7.18. |
| etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.5.33, 3.6.14, and 3.7.1, a network attacker who can reach an etcd TLS listener can open many TCP connections and never send a ClientHello. In client/pkg/transport/listener_tls.go, each connection handled by tlsListener.acceptLoop spawns a goroutine that blocks indefinitely inside tls.Conn.Handshake() and remains tracked in the pending map. Unbounded goroutine and map growth can exhaust memory in the etcd process, causing loss of availability for the cluster and, when etcd backs Kubernetes, the control plane. This issue is fixed in versions 3.5.33, 3.6.14, and 3.7.1. |
| Http4s (http4s-blaze-server) is a minimal, idiomatic Scala interface for HTTP services. Prior to 0.23.18 and 1.0.0-M42, http4s-blaze-server aggregates fragments of an incoming WebSocket message with no limit on total size or fragment count. A client that completes a WebSocket handshake can send an unterminated fragmented message and drive unbounded heap growth in the server JVM, resulting in denial of service through OutOfMemoryError. Any http4s application serving WebSocket routes over BlazeServerBuilder is affected, no non-default configuration is required, and maxWebSocketBufferSize does not bound the aggregate because it bounds only individual frames. A single connection sending continuation frames that never set FIN forces the server to buffer every fragment until the heap is exhausted, terminating the JVM with OutOfMemoryError on the blaze selector thread. Small fragments amplify the cost through per-frame object overhead, so a modest volume of wire bytes is sufficient. This issue is fixed in versions 0.23.18 and 1.0.0-M42. |
| Issue summary: When an OpenSSL QUIC server (Listener SSL object) processes
valid QUIC Initial packets for unknown destination connection IDs, it
can allocate and queue new incoming channels without enforcing any limit.
Impact summary: A remote peer that can make many Initial packets reach the
server listener faster than the application accepts connections, can cause the
memory allocated to store the per-channel state to grow without any limits,
potentially making the QUIC listener unavailable and causing Denial of Service.
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: The function that handles inbound QUIC packets uses
Connection-Id from the packet header to find an existing connection
(QUIC channel). If no existing connection is found and the packet
type is INITIAL, the function treats the packet as a new connection. It
allocates a new channel object and inserts it into a queue where it
waits to be accepted by the local application with SSL_accept(3ossl).
The memory occupied by these initial channel objects may grow
without bounds if the application is not able to call SSL_accept()
frequently enough to serve these inbound connection requests.
The issue is present since OpenSSL 3.5 when the QUIC server implementation
was added.
The fix introduces a limit for pending connections. The default limit is set
to 256 pending connections (waiting to be accepted by the local application).
Applications may change the default by calling SSL_set_value_uint(3ossl).
FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary. |
| In the Linux kernel, the following vulnerability has been resolved:
gpio: rockchip: teardown bugs and resource leaks
Address several teardown issues and resource leaks in the driver's remove
path and error handling:
1. Debounce clock reference leak: The debounce clock (bank->db_clk) is
obtained using of_clk_get() which increments the clock's reference
count, but clk_put() is never called. Register a devm action to
cleanly release it on unbind. Note that of_clk_get(..., 1) remains
necessary over devm_clk_get() because the DT binding does not define
clock-names, precluding name-based lookup.
2. Unregistered chained IRQ handler: The chained IRQ handler is not
disconnected in remove(). If a stray interrupt fires after the driver
is removed, the kernel attempts to execute a stale handler, leading
to a panic. Fix this by clearing the handler in remove().
3. IRQ domain leak: The linear IRQ domain and its generic chips are
allocated manually during probe but never removed. Remove the IRQ
domain during driver teardown to free the associated generic chips
and mappings.
[Bartosz: don't emit an error message on devres allocation failure] |
