O reprodutor foi executado com o arquivo de disparo fornecido:

A execução reproduziu uma falha de segmentação causada por uma leitura de memória inválida. O rastreamento de pilha do AddressSanitizer identificou a falha durante uma operação memmove chamada a partir de TIFFReadRGBATileExt.

Análise da Causa Raiz

Usando GDB, a condição da falha foi reproduzida com os seguintes valores em tempo de execução:

O código vulnerável então executou:

Com os valores observados, este cálculo é:

Como read_ysize não tem sinal, o resultado foi envolvido para:

que é UINT32_MAX.

O valor de read_ysize foi posteriormente usado no cálculo do ponteiro de origem para memmove.

Imediatamente antes do memmove que falhou, o GDB mostrou:

O ponteiro de destino avaliado para:

que era o início do buffer raster.

O ponteiro de origem avaliado para:

O ponteiro de origem calculado estava 17179869176 bytes, aproximadamente 16 GiB, além do início do buffer raster.

A execução do memmove no GDB resultou em:

O backtrace mostrou o seguinte caminho da falha:

Isso confirma que o underflow sem sinal em read_ysize produziu um deslocamento de origem fora dos limites. O ponteiro de origem inválido resultante foi então usado por memmove, causando uma leitura de memória inválida e uma falha de segmentação.

Análise do Patch e Validação da Correção

A correção upstream adicionou uma verificação explícita de limites antes do cálculo vulnerável de read_ysize:

Usando GDB na versão corrigida, os seguintes valores em tempo de execução foram observados:

Para esses valores, a nova condição de validação é avaliada como verdadeira porque:

A função portanto relatou:

e retornou 0.

Como resultado, a execução não alcançou o cálculo vulnerável:

Isso impede o underflow sem sinal observado na versão vulnerável e impede que o valor inválido seja usado no cálculo posterior do ponteiro de origem do memmove.

Análise do Reproduzir e Pré-condições

O reprodutor original calcula incorretamente o número de tiles ao longo do eixo Y.

O código relevante passa o valor de retorno de TIFFGetField() diretamente como a coordenada Y para TIFFComputeTile():

Usando GDB, observou-se que tile_height continha:

No entanto, TIFFGetField() retornou:

O valor de retorno indica sucesso; não é a altura da imagem. Portanto, a chamada efetivamente se torna:

Para este TIFF, o GDB mostrou que esta chamada retorna:

Este valor é um índice de tile, não o número de tiles ao longo do eixo Y.

O reprodutor original então usou este valor em seu cálculo de num_tiles_y, resultando em:

No entanto, as dimensões da imagem e as dimensões dos tiles são:

Portanto, o número correto de tiles ao longo do eixo Y é:

O valor incorreto de 63 faz com que o loop itere com valores Y de 0 a 62, mesmo que a altura da imagem seja 33 e as coordenadas Y válidas sejam apenas 0 a 32.

Isso permite que um valor inválido como:

seja passado para TIFFReadRGBATileExt.

A versão vulnerável do libtiff não rejeitou esta coordenada fora do intervalo antes de realizar o cálculo sem sinal img.height - row. Isso permitiu que a entrada de API inválida gerada pelo reprodutor se tornasse uma falha de segurança de memória.

O reprodutor corrigido fornecido pelo mantenedor calcula o número de tiles diretamente a partir das dimensões da imagem e dos tiles.

Para o mesmo TIFF, o cálculo corrigido produz:

O reprodutor corrigido foi testado contra a mesma versão vulnerável do libtiff e o mesmo arquivo de disparo.

O programa saiu com status 0, e nenhum relatório de AddressSanitizer ou SIGSEGV foi produzido.

Isso apoia a observação do mantenedor de que o reprodutor original contém um cálculo incorreto de contagem de tiles. No entanto, a versão vulnerável do libtiff ainda carecia de validação defensiva de linha e coluna, permitindo que coordenadas de API inválidas resultassem em uma falha de segurança de memória.

Resumo da Validação

Conclusão

A falha em TIFFReadRGBATileExt ocorre quando uma coordenada de imagem fora do intervalo alcança a implementação vulnerável do libtiff.

No reprodutor original, um cálculo incorreto de contagem de tiles faz com que num_tiles_y seja calculado como 63 em vez do valor correto 33. Como resultado, o reprodutor pode passar uma linha fora do intervalo válido da imagem para TIFFReadRGBATileExt.

Na versão vulnerável do libtiff, os argumentos de linha e coluna não eram validados antes do cálculo:

Para o caso reproduzido, row era 34 enquanto img.height era 33. Como read_ysize não tem sinal, a subtração sofreu underflow para UINT32_MAX. Este valor foi subsequentemente usado no cálculo do ponteiro de origem para memmove, produzindo uma leitura de memória inválida e uma falha de segmentação.

A correção upstream adiciona validação explícita de limites de linha e coluna antes deste cálculo. O teste da versão corrigida confirmou que a mesma coordenada inválida é rejeitada antes que o underflow e o memmove possam ocorrer.

O reprodutor corrigido fornecido pelo mantenedor também foi testado contra a versão vulnerável usando o mesmo arquivo TIFF. Ele calculou a contagem correta de tiles e foi concluído sem um relatório de AddressSanitizer ou SIGSEGV.

Portanto, esta análise não estabelece que o arquivo TIFF sozinho dispara a falha de segurança de memória quando a API é usada corretamente. O reprodutor original contém um cálculo incorreto de contagem de tiles, enquanto a implementação histórica do libtiff carecia de validação defensiva de limites e permitia que a entrada de API inválida resultante se tornasse uma falha de segurança de memória.