Dyingc

A flaw in the application-layer body-handler occurs when a `POST /ubus` request arrives in multiple TCP segments. The function `uh ubus data send()` in `ubus.c` can desynchronize HTTP request boundaries if an initial segment completes a JSON object, causing subsequent segments to trigger a parse-error path that returns zero bytes consumed. Because the caller does not drain the remaining `Content-Length` or set `connection close`, any HTTP request embedded in the unread body suffix is processed as a new request on the same keep-alive connection. This issue affects deployments with ubus enabled, such as default OpenWrt configurations and certain proxy or CDN deployments.

The `client poll post data()` function in `client.c` fails to properly handle invalid chunk-length lines, such as sizes exceeding `INT MAX`. When this occurs, the server clears `r->content length` and `r->transfer chunked` without draining the remaining body or setting `request.connection close`. This causes the completion check to incorrectly treat the chunked POST as finished, returning the keep-alive parser to `CLIENT STATE INIT`. Consequently, attacker-controlled body bytes formatted as a complete HTTP request are parsed and processed as a separate request on the same connection, leading to HTTP request smuggling and request-boundary desynchronization.

The `client parse header()` function in `client.c` lowercases header names but uses a case-sensitive `strcmp` to compare the `Transfer-Encoding` value to `chunked`. Because transfer-coding tokens are case-insensitive, a mixed-case token is accepted without enabling `r->transfer chunked`. On a keep-alive connection, the `chunked` POST body remains unread, causing request-shaped body bytes to be parsed as a subsequent HTTP request. This leads to HTTP request smuggling and boundary desynchronization.

An out-of-bounds array write exists in the h.265 video codec implementation. A crafted H.265 bitstream can trigger this issue within the `decoder context::process reference picture set()` function. The problem stems from a missing aggregate bound check on predicted short-term reference picture set entries; while individual list sizes are validated, the combined count after construction can exceed the 16-entry `PocStFoll` array, resulting in a write at index 16. This memory corruption could potentially allow an attacker to execute arbitrary code.

An issue in the h.265 video codec implementation allows a crafted sequence of H.265 NAL units to cause the `decoder context::read slice NAL()` function to attach slice headers to a finished picture object that lacks an active image unit. This leads to attacker-controlled unbounded heap growth, as the retained headers are not freed until the picture is released, which may not occur during continuous streaming.

An issue exists in the h.265 video codec implementation where a crafted H.265 bitstream containing large SPS dimensions and 16-bit bit depth triggers a signed integer overflow in the `de265 image get buffer()` function. This overflow results in the plane allocation size being wrapped to a small value of approximately 1 KB. Subsequently, the `fill image()` function calculates the actual size using `size t`, leading to approximately 4 GB of data being written into the undersized heap buffer, which can cause a denial of service.