Daniel Birtwhistle

Um servidor HTTP/2 malicioso ou comprometido pode causar a falha de um aplicativo ao reter um SETTINGS ACK e enviar um RST STREAM em um fluxo concluído para plantar um ponteiro nulo. Subsequentemente, o envio de um PUSH PROMISE para esse fluxo desencadeia uma desreferenciação de ponteiro nulo na classe `QNetworkAccessManager`. Uma desreferenciação de ponteiro nulo ocorre quando um programa tenta ler ou gravar em um endereço de memória que é NULL, levando geralmente a um travamento imediato.

Um problema de use-after-free no suporte ao cliente HTTP/2 do módulo Qt Network, dentro do QNetworkAccessManager, permite que um servidor HTTP/2 malicioso ou comprometido cause a falha do aplicativo cliente, afetando a disponibilidade. O use-after-free ocorre quando um programa continua a usar um ponteiro após ele ter sido liberado, o que pode levar a falhas ou execução de código arbitrário.

A conclusão de referência direta para IDs de objeto `@JsonIdentityInfo` realiza uma varredura linear do acumulador de referências pendentes para cada ID resolvido. Isso ocorre na função `CollectionDeserializer.CollectionReferringAccumulator.resolveForwardReference()` e na implementação correspondente em `MapDeserializer`. Se um documento cria N referências de ID de objeto não resolvidas em uma coleção ou mapa habilitado por identidade e, posteriormente, define esses IDs em ordem inversa, o sistema executa um trabalho de CPU quadrático durante a desserialização. Isso permite que um documento raso cause consumo excessivo de CPU por meio de um grande número de comparações de identidade.

A função ` findDeserializer()` em `TypeDeserializerBase` armazena em cache os desserializadores resolvidos usando o ID de tipo bruto fornecido pelo usuário. Em configurações que utilizam polimorfismo baseado em nome com um fallback, como `@JsonTypeInfo(use = Id.NAME, defaultImpl = ...)`, cada ID de tipo não reconhecido e único é armazenado como uma chave separada no mapa ` deserializers`, embora todos resolvam para o mesmo desserializador de fallback. Como esse mapa não possui um limite configurável e persiste durante a vida útil do desserializador de tipo, um invasor pode causar retenção contínua de memória ao fornecer inúmeros IDs de tipo desconhecidos e únicos. Este problema ocorre quando uma aplicação habilita o polimorfismo baseado em nome com um `defaultImpl` ou fallback similar, aceita IDs de tipo influenciados pelo usuário e utiliza um `ObjectMapper` de longa duração entre as requisições.

Um invasor remoto pode criar um comando Openwire RemoveSubscriptionInfo para causar a exclusão de uma fila no broker Artemis. Esta ação pode ocorrer antes da etapa de autenticação e autorização da conexão ou a qualquer momento posterior.

Um subfluxo de inteiro (integer underflow) existe no código de captura de pacotes DHCPv4 do cliente `wickedd-dhcp4`. A função `ni capture inspect udp header()` em `src/capture.c` não verifica se o campo de comprimento total do IP `ip len` é pelo menos tão grande quanto o comprimento do cabeçalho IP `ihl` antes de realizar a subtração. Um invasor não autenticado na mesma rede pode explorar isso para desencadear uma leitura fora dos limites (out-of-bounds read) além do buffer de recebimento, podendo causar a falha do daemon dependendo do layout da memória do processo.

Uma leitura fora dos limites (out-of-bounds read) existe no código de captura de pacotes DHCPv4. A função `ni capture inspect udp header()` em `src/capture.c` reporta incorretamente o comprimento total do IP como o comprimento da carga útil (payload), em vez do comprimento da carga útil UDP restante. Consequentemente, o manipulador de opções DHCP no cliente DHCPv4 (`wickedd-dhcp4`) lê até 68 bytes além do final do buffer de recebimento de pacotes de 1500 bytes. Um invasor não autenticado na mesma rede pode enviar um pacote DHCP/UDP manipulado para fazer com que o cliente analise a memória adjacente do heap como opções DHCP, permitindo que conteúdos do heap, como metadados do alocador ou valores de ponteiros, sejam interpretados como campos de concessão (lease fields).

Um estouro de buffer baseado em heap no mecanismo de dissecação pode levar a um travamento, resultando em negação de serviço. Um estouro de buffer baseado em heap ocorre quando um programa grava mais dados em um buffer de memória heap do que ele pode suportar, potencialmente corrompendo a memória.

Uma falha no analisador de arquivos TTL pode levar a um loop infinito, resultando em negação de serviço.

Uma falha no analisador de arquivos PEAK CAN TRC pode causar a negação de serviço.