Claude

A flaw was found in GStreamer's gst-plugins-good, specifically in the H.264 RTP depayloader element. When processing MTAP16 or MTAP24 multi-time aggregation RTP packets, a signed/unsigned integer conversion error causes the remaining-length counter to underflow to a large positive value when the packet is truncated. This allows a remote, unauthenticated attacker to trigger an out-of-bounds heap read of up to approximately 64 KiB of process memory by sending a single malformed RTP packet. Successful exploitation can crash the receiving GStreamer pipeline (denial of service), and in relay or transcoding deployments where output is accessible to the attacker, may expose adjacent heap contents.

On MPU-enabled ports with queue sets enabled, the queue-set selection system call lacks proper type validation. This allows a local unprivileged task to write actor-controlled data beyond a pointer-sized object on the privileged kernel stack, which impacts privileged memory across the MPU (Memory Protection Unit) isolation boundary.

Resource exhaustion occurs across all platforms due to multiple parsers failing to limit sizes declared by the client or the size of decompressed output. This allows attackers to cause disproportionate memory consumption and crash the process. The issue stems from several root causes: gzip, zlib, and snappy decompressors do not enforce output limits, as `-max body size` only checks compressed bytes; AMF string readers allocate declared lengths before bytes are available; RTMP chunk headers allow unbounded message length re-declarations mid-stream; the sofa-pbrpc parser does not bound `meta size`; and mcpack2pb trusts wire-declared item counts for `Reserve()`, where a `value size` of 0 can cause a buffer size underflow.

A NULL pointer dereference in the RTMP protocol implementation allows remote attackers to cause a denial of service by crashing the server. This occurs when the `RtmpService::NewStream()` function returns a null stream to reject a `createStream` command. If the server fails to write the rejection response to the client—such as when a client closes the connection immediately after sending the command—the error-handling path in the `RtmpChunkStream::OnCreateStream()` function attempts to access the `stream-> onfail id` variable using the null pointer, leading to a process crash.

The Discovery naming-service reply parser fails to validate that JSON values are objects before calling RapidJSON object-only accessors. A malformed response containing non-object entries in the data, service members, or instances list can trigger an out-of-bounds memory read, potentially crashing the client. This occurs within the `DiscoveryNamingService::GetServers()` and `DiscoveryNames::ListDiscoveryNodes()` functions in the `src/brpc/policy/discovery naming service.cpp` file. The issue can be triggered if a compromised or misconfigured Discovery backend returns malformed responses via the '/discovery/nodes' or '/discovery/fetchs' endpoints.

Unbounded memory accumulation in the stream message reassembly path allows remote attackers to cause a denial of service by sending an endless sequence of continuation data frames. While the streaming RPC protocol bounds individual data frames by `max body size`, fragmented stream messages accumulate continuation frames into the ` pending buf` buffer without a size limit. Because default flow-control settings (`socket max streams unconsumed bytes=0`) do not throttle the sending rate, a malicious peer can force the receiver to accumulate an arbitrarily large in-memory message, leading to memory exhaustion and system crashes. This affects services accepting streams from untrusted clients via `brpc::StreamAccept` or `brpc::StreamCreate` using the built-in streaming protocol.

Missing authentication in the streaming RPC path allows a remote attacker to bypass server authentication and inject or deliver streaming frames when a server is configured with an Authenticator. This occurs because streaming RPC frames are consumed directly by the `ParseStreamingMessage()` function and bypass the authentication hook in `InputMessenger`. Additionally, server-accepted streams are bound lazily to the first frame carrying their id, potentially allowing a stream to accept a frame from a socket other than the one that created the stream.

Uncontrolled resource consumption in the HTTP/2 (h2) receive path allows a remote unauthenticated attacker to crash the server or cause unbounded memory growth by sending crafted HTTP/2 frames. The h2 parser, enabled by default on every server port and used by h2/gRPC clients, fails to enforce receive-side limits. Specifically, the server does not check `SETTINGS MAX CONCURRENT STREAMS`, allowing an unbounded number of pending streams per connection. Additionally, `SETTINGS MAX HEADER LIST SIZE` is not enforced, enabling an HPACK bomb where small HEADERS frames are amplified into massive decoded header lists, or memory accumulates via incomplete HEADERS/CONTINUATION blocks. Control-frame acknowledgments (including PING, SETTINGS, RST STREAM, GOAWAY, and WINDOW UPDATE) bypass the `-socket max unwritten bytes` write cap, allowing connection buffers to grow during a PING flood. Finally, the HPACK dynamic table size update is validated against a protocol default instead of the advertised `SETTINGS HEADER TABLE SIZE`, which can lead to decoder desynchronization and a NULL pointer dereference crash.

Uncontrolled resource consumption in the streaming RPC component allows a remote attacker to cause a denial of service by exhausting server memory. This occurs when a client sends a single RPC request containing an excessive number of stream identifiers within the `stream settings.extra stream ids` field of the RPC meta. The server-side `StreamAccept()` function creates a response stream for every declared identifier without imposing a limit. Since the request body size is bounded by `max body size` (default 64MB), it can accommodate millions of identifiers. Each stream allocates a bthread execution queue and associated resources, leading to memory exhaustion.

An enforceable assertion in the streaming feature allows a remote, unauthenticated attacker to crash the server process, leading to a denial of service. This occurs when the server handles `FRAME TYPE FEEDBACK` frames and calls the `Stream::SetRemoteConsumed()` function. The process aborts if a feedback frame contains an unexpected payload or is received on a stream where flow control is disabled, triggering failures in the `CHECK( cur buf size > 0)` and `CHECK(buf.IsEmpty())` assertions.

Improper authorization allows remote attackers to access builtin services through the public port. While the `ServerOptions.internal port` is intended to restrict builtin and Tabbed services to the internal port, protobuf-based protocol dispatch paths (including baidu std, hulu pbrpc, sofa pbrpc, public pbrpc, nshead mcpack, nova pbrpc, and ubrpc2pb) calculate the `security mode` flag but fail to enforce it between method resolution and invocation. Consequently, clients accessing the public port can invoke builtin services such as `brpc.vars` or `hotspots` to disclose sensitive runtime information, including metrics, flags, and profiler data.

Inconsistent interpretation of HTTP requests in the bundled HTTP/1.1 parser allows remote attackers to smuggle requests and inject headers when the software is deployed behind a proxy or load balancer that parses bytes differently. This occurs because the parser accepts several HTTP/1.1 header forms that conforming front-ends may reject or interpret differently, leading to desynchronization between the two parsers. Technical details include the acceptance of spaces before colons in framing headers, skipping interior spaces within the `Content-Length` value, and accepting obsolete line folding (obs-fold) for `Content-Length` and `Transfer-Encoding` values. Additionally, chunked trailer fields are merged into the header map, potentially allowing the smuggling of fields such as `Authorization` or `X-Forwarded-For`. Furthermore, `Transfer-Encoding` lists with optional whitespace after a comma may not be recognized as chunked, causing response desynchronization.

An interpretation conflict in the HTTP protocol implementation allows remote attackers to bypass access control rules enforced by a front proxy. The `FindMethodPropertyByURI()` function splits the request path using a string splitter that skips empty fields. Consequently, paths with consecutive slashes (empty path segments), such as `//flags`, are treated as the collapsed form `/flags`. Because a front proxy enforcing an Access Control List (ACL) may only match the collapsed form, it may forward the padded literal to the bRPC server, which then dispatches it to the restricted service. Additionally, the HTTP/2 implementation fails to validate the `:path` pseudo-header, allowing requests that do not begin with `/` or are not the asterisk-form `*` to be processed, contrary to RFC 9113.

An out-of-bounds read exists in the streaming RPC client across all platforms. When a client creates multiple streams in a single RPC, it expects the server response to contain exactly one `extra stream id` for every additional stream. The response handling path in the `Controller::HandleStreamConnection()` function indexes the returned identifiers using the locally created stream count without validating the size of the returned list. A malicious or compromised server, or an on-path attacker, can trigger this by returning a malformed StreamSettings response with fewer `extra stream ids` than expected. This can lead to a client process crash (denial of service) or the leakage of unintended memory contents into subsequent stream handling.

A null pointer dereference exists in the IKEv2 state machine within the EAP handling code for authentication. Due to an inconsistency in the state machine code, a fall-through occurs where the system incorrectly dereferences the `ike->sa.st eap` variable while it is NULL. This issue can be triggered by any IKEv2 connection via a malicious IKE AUTH packet, regardless of whether EAP is configured, and does not require the peer to be authenticated. Exploitation leads to a crash and subsequent restart of the pluto daemon, which can result in a denial of service. Remote code execution is not possible.

A null pointer dereference exists in the PKCS#7 handling code used for IKE certificate authentication. The issue occurs when decoding an IKE CERT payload of type `CERT PKCS7 WRAPPED X509`. The software uses `SEC PKCS7ContainsCertsOrCrls()` to validate the PKCS#7 blob and subsequently uses `SEC PKCS7GetCertificateList()` to iterate the certificate list. A discrepancy between these two NSS APIs allows a SignedData object containing a CRL (Certificate Revocation List) but no certificates to pass the initial guard, while the subsequent list retrieval returns NULL. This leads to a null pointer dereference, causing the system to crash and restart. An unauthenticated peer can trigger this behavior by sending a malicious `IKE AUTH` packet, potentially resulting in a denial of service through repeated exploitation.

A heap-based buffer overflow write exists in the read-only dictionary loader. The `String::reserve()` function in `common/string.hpp` performs a capacity check using a signed integer `((int)s + 1)`, which allows a requested size of `0x7FFFFFFF` to wrap to a negative value, preventing the backing buffer from growing. The `ReadOnlyDict::load()` function in `modules/speller/default/readonly ws.cpp` passes unvalidated 32-bit size fields from a `.rws` dictionary header into this path. Consequently, a crafted `.rws` file containing a valid endian marker and an oversized length field, such as `lang name size` set to `0x7FFFFFFF`, allows attacker-controlled data to be written out of bounds past an undersized heap allocation. This can lead to heap memory corruption, resulting in denial of service or potential code execution if a victim is induced to load a malicious dictionary.

Inefficient algorithmic complexity in X.509 distinguished name string conversion within the `X509Name.ToString` and `IetfUtilities.ValueToString` functions allows a remote unauthenticated attacker to cause a denial of service through CPU exhaustion. This occurs when processing a certificate, CRL, certification request, or other structure containing a long attribute value composed of leading or trailing spaces or characters that require escaping, such as commas. The issue arises because each escaping backslash is inserted into the buffer being scanned, causing the workload to grow quadratically relative to the value length. Applications are susceptible when converting such names to strings for logging or display, or when comparing them using the `IetfUtilities.RdnAreEqual` function, as seen in PKIX path validation for `directoryName` name constraints.

Remote unauthenticated attackers can cause a denial of service through memory exhaustion by providing a specially crafted HSS public key and signature. The issue occurs because the level count `L` read during the parsing of an HSS public key in the `HssPublicKeyParameters` and `HssSignature` code is not validated against the RFC 8554 maximum limit of 8. Consequently, the signature parsing process allocates an array of `L - 1` entries before processing further data, which can lead to a single verification committing up to 17 GB of memory or triggering an `OutOfMemoryException`.

In the stream mode of `IesEngine` (when constructed without a block cipher), the message authentication key is exposed through the encryption keystream. A remote attacker who has observed one encrypted message with known plaintext can forge shorter messages that the recipient accepts as authentic by using a crafted ciphertext and MAC tag. This occurs because the MAC key is derived from the output directly after a keystream as long as the message, while the derivation input depends only on the static key pair and fixed parameters. Consequently, the keystream revealed by a single message contains the MAC key for all sufficiently shorter messages.