Ron Edgerson

As versões do TinyOS até e incluindo a 2.1.2 possuem um problema de estouro de buffer global na implementação de saída formatada `printfUART` dentro da pilha de rede ZigBee / IEEE 802.15.4. A função `printfUART` utiliza `strcat()` sem verificar a capacidade restante do buffer ao formatar a saída em um buffer global de tamanho fixo. Se `printfUART` for chamada com uma string mais longa que o tamanho do buffer, ela pode escrever além do final do buffer `debugbuf`, levando à corrupção de memória global. Isso pode resultar em negação de serviço, comportamento inesperado ou divulgação de informações através de estado global corrompido ou saída UART.

As versões do TinyOS até e incluindo a 2.1.2 apresentam uma vulnerabilidade de estouro de buffer baseado em pilha no utilitário mcp2200gpio. Isso se deve ao uso inseguro das funções `strcpy()` e `strcat()` ao criar caminhos de dispositivo durante a descoberta automática de dispositivos. Um atacante local pode explorar isso criando nomes de arquivos especialmente elaborados no diretório `/dev/usb/`, o que pode causar corrupção de memória da pilha e falhas na aplicação.

As versões do RIOT OS até e incluindo a 2026.01-devel-317 apresentam uma vulnerabilidade de estouro de buffer baseado em pilha no utilitário tapslip6. Isso ocorre devido à concatenação insegura de strings na função `devopen()`. O utilitário utiliza `strcpy()` e `strcat()` para combinar um prefixo fixo '/dev/' com um nome de dispositivo fornecido pelo usuário na opção de linha de comando `-s`, sem verificação de limites suficiente. Um atacante pode fornecer um nome de dispositivo excessivamente longo, causando um estouro de buffer na pilha, o que pode levar a falhas no processo e corrupção de memória.

Versões do RIOT OS até e incluindo 2026.01-devel-317 apresentam um problema de estouro de buffer baseado em pilha no utilitário ethos. Isso ocorre devido à falta de verificação de limites ao manipular dados de quadro serial de entrada. O problema está presente na função ` handle char()`, onde os bytes de quadro de entrada são adicionados a um buffer de pilha de tamanho fixo sem garantir que o índice de escrita permaneça dentro dos limites do buffer. Um invasor que envie entradas serial ou com quadro TCP especialmente elaboradas pode fazer com que o índice de escrita ultrapasse o tamanho do buffer, levando à corrupção de memória e falhas do aplicativo.

O deploy-stub do Panda3D contém uma condição de negação de serviço resultante de alocação de pilha ilimitada. O executável deploy-stub usa `alloca()` para alocar `argv copy` e `argv copy2` com base no valor de `argc`, que é diretamente controlado pelo atacante, sem qualquer validação. Fornecer um grande número de argumentos de linha de comando pode esgotar o espaço da pilha e levar a uma falha e comportamento indefinido durante a inicialização do interpretador Python.

O utilitário egg-mkfont do Panda3D contém uma vulnerabilidade de string de formato não controlada. A opção de linha de comando `-gp` é usada diretamente como a string de formato para a função `sprintf()` com um único argumento. O fornecimento de especificadores de formato adicionais por um atacante pode levar à leitura de valores não intencionais da pilha e à gravação da saída formatada nos arquivos `.egg` e `.png` gerados, potencialmente expondo memória residente na pilha e valores de ponteiro.

O software contém uma vulnerabilidade de estouro de buffer na pilha devido ao uso de uma chamada `sprintf()` sem limites com entrada controlada por um invasor. Ao criar nomes de arquivos de glifos, o software formata um padrão de glifo fornecido pelo usuário (`-gp`) em um buffer de pilha de tamanho fixo sem validar o comprimento. Fornecer uma string de padrão de glifo excessivamente longa pode causar o estouro do buffer da pilha, levando à corrupção de memória e a uma falha. Dependendo da configuração de compilação e do ambiente de execução, este estouro também pode permitir a execução arbitrária de código.

O software contém um underflow de buffer heap na função `readline()` do `mdb load`. O processamento de entrada malformada com um byte NUL embutido pode causar um underflow no cálculo de offset sem sinal, resultando em uma leitura fora dos limites de um byte antes do buffer heap alocado. Isso pode levar a uma condição de negação de serviço devido a um crash.

As versões do Bio-Formats até a 8.3.0 inclusive contêm uma vulnerabilidade de Entidade Externa XML (XXE) no componente de análise de metadados da Leica Microsystems, como o XLEF. O analisador utiliza um DocumentBuilderFactory configurado de forma insegura ao processar arquivos de metadados baseados em XML da Leica, permitindo a expansão de entidades externas e o carregamento de DTD externo. Um arquivo de metadados manipulado pode desencadear solicitações de rede de saída (SSRF), acessar recursos locais do sistema que estejam legíveis ou causar uma negação de serviço durante a análise XML.

As versões do Bio-Formats até a versão 8.3.0, inclusive, são suscetíveis à desserialização Java insegura de arquivos de cache de memoização (.bfmemo) controlados por um atacante durante o processamento de imagens. A classe `loci.formats.Memoizer` carrega e desserializa automaticamente arquivos memo associados às imagens sem validação ou verificação de confiança. Um atacante que forneça um arquivo .bfmemo manipulado junto com uma imagem pode desencadear a desserialização de dados não confiáveis, potencialmente levando a negação de serviço, manipulação lógica ou execução remota de código, caso existam cadeias de gadgets adequadas no classpath. A desserialização Java é um processo no qual um fluxo de bytes é convertido novamente em um objeto. Neste caso, a falta de validação permite que um atacante controle os dados a serem desserializados, potencialmente executando código malicioso.

As versões do zlib até e incluindo 1.3.1.2 contêm um estouro de buffer global no utilitário `untgz`. A função `TGZfname()` utiliza uma chamada `strcpy()` não limitada para copiar um nome de arquivo fornecido pelo atacante de `argv[]` para um buffer global estático de tamanho fixo de 1024 bytes, sem validar o comprimento. Fornecer um nome de arquivo com mais de 1024 bytes resulta em uma escrita fora dos limites, potencialmente levando à corrupção de memória, negação de serviço e execução de código, dependendo do compilador, flags de compilação, arquitetura e layout de memória. Esse estouro ocorre antes de qualquer análise ou validação do arquivo.