Dyingc

Uma falha no manipulador de corpo da camada de aplicação ocorre quando uma requisição `POST /ubus` chega em múltiplos segmentos TCP. A função `uh ubus data send()` em `ubus.c` pode dessincronizar os limites da requisição HTTP se um segmento inicial completar um objeto JSON, fazendo com que segmentos subsequentes acionem um caminho de erro de análise que retorna zero bytes consumidos. Como o chamador não drena o `Content-Length` restante nem define `connection close`, qualquer requisição HTTP incorporada no sufixo do corpo não lido é processada como uma nova requisição na mesma conexão keep-alive. Este problema afeta implantações com ubus habilitado, como configurações padrão do OpenWrt e certas implantações de proxy ou CDN.

A função `client poll data()` em `client.c` não processa corretamente linhas de comprimento de chunk inválidas, como tamanhos que excedem `INT MAX`. Quando isso acontece, o servidor limpa `r->content length` e `r->transfer chunked` sem drenar o corpo restante ou definir `request.connection close`. Isso faz com que a verificação de conclusão trate incorretamente o POST chunked como finalizado, retornando o analisador de keep-alive para `CLIENT STATE INIT`. Consequentemente, bytes do corpo controlados por um invasor e formatados como uma requisição HTTP completa são analisados e processados como outra requisição na mesma conexão, causando contrabando de requisições HTTP (HTTP request smuggling) e dessincronização de limite de requisição.

A função `client parse header()` em `client.c` converte os nomes dos cabeçalhos para letras minúsculas, mas utiliza `strcmp` sensível a maiúsculas e minúsculas para comparar o valor de `Transfer-Encoding` com `chunked`. Como os tokens de codificação de transferência não diferenciam maiúsculas de minúsculas, um token com letras mistas é aceito sem ativar `r->transfer chunked`. Em uma conexão keep-alive, o corpo POST `chunked` permanece não lido, fazendo com que bytes do corpo com formato de requisição sejam interpretados como outra requisição HTTP. Isso permite o contrabando de requisições HTTP (HTTP request smuggling) e a dessincronização de fronteiras.

Uma gravação de array fora dos limites existe na implementação do codec de vídeo h.265. Um fluxo de bits H.265 manipulado pode desencadear este problema na função `decoder context::process reference picture set()`. O problema decorre de uma verificação de limite agregada ausente em entradas de conjunto de imagens de referência de curto prazo previstas; embora os tamanhos de lista individuais sejam validados, a contagem combinada após a construção pode exceder o array `PocStFoll` de 16 entradas, resultando em uma gravação no índice 16. Esta corrupção de memória poderia potencialmente permitir que um invasor execute código arbitrário.

Um problema na implementação do codec de vídeo h.265 permite que uma sequência manipulada de unidades NAL H.265 faça com que a função `decoder context::read slice NAL()` anexe cabeçalhos de fatia (slice headers) a um objeto de imagem finalizado que não possui uma unidade de imagem ativa. Isso resulta em um crescimento ilimitado da memória heap controlado pelo invasor, pois os cabeçalhos retidos não são liberados até que a imagem seja liberada, o que pode não acontecer durante a transmissão contínua.

Existe um problema na implementação do codec de vídeo h.265 onde um fluxo de bits H.265 manipulado contendo dimensões SPS grandes e profundidade de bits de 16 bits desencadeia um estouro de inteiro assinado na função `de265 image get buffer()`. Esse estouro resulta no tamanho da alocação do plano sendo reduzido para um valor pequeno de aproximadamente 1 KB. Subsequentemente, a função `fill image()` calcula o tamanho real usando `size t`, levando a aproximadamente 4 GB de dados sendo gravados no buffer de heap subdimensionado, o que pode causar a negação de serviço.