Gzip 1.15 corrige corrida que apagava o arquivo errado

O Gzip 1.15 foi lançado em 20 de setembro de 2026 e corrige uma falha que podia fazer o gzip apagar o arquivo errado. Jim Meyering anunciou a versão na lista de discussão info-gnu do GNU. A maioria das falhas corrigidas está no gzip desde o início. Ou seja, há scripts rodando sobre elas há décadas.

O gzip é o programa de compressão por trás dos arquivos .gz que acompanham quase todos os sistemas Linux e Unix. Ele está embutido em gerenciadores de pacotes, rotinas de backup e rotação de logs. Um defeito nele alcança muito mais máquinas do que seu perfil discreto sugere.

Esta versão traz 119 commits escritos ao longo de 75 semanas. Paul Eggert assinou 88 deles e Meyering 24, com contribuições menores de Mark Adler, Bruno Haible e Collin Funk. A versão anterior, gzip 1.14, saiu em abril de 2025 segundo o Phoronix.

O que a falha de exclusão fazia

O gzip normalmente compacta um arquivo e depois remove o original. A falha estava justamente em determinar qual arquivo remover.

O anúncio expõe a correção com clareza: "o gzip não pode mais remover por engano o arquivo errado se outro processo renomear simultaneamente um diretório ancestral do destino do gzip". Ancestral aqui significa qualquer diretório acima do arquivo de destino.

O perigo aparece, portanto, quando duas coisas acontecem ao mesmo tempo. O gzip está no meio do trabalho e outro processo renomeia uma pasta do caminho. O gzip resolve o caminho de novo e pode chegar a um arquivo diferente do inicial.

Isso é uma condição de corrida, ou race condition. O resultado depende de como dois programas separados coincidem no tempo. Como essa coincidência é necessária, o caso é raro. Em um servidor cheio de tarefas automáticas, raro não é o mesmo que nunca.

Um segundo problema de travamento também foi corrigido. A sincronização podia falhar em sistemas que aceitam as flags de arquivo O_PATH ou O_SEARCH. Esse é mais novo que os demais: chegou no gzip 1.7.

Três correções na decodificação .lzh

O gzip ainda lê arquivos .lzh, um formato de compressão antigo muito usado no Japão. Três das correções estão nesse decodificador.

Uma delas é de segurança de memória. O anúncio relata que "um estouro de buffer foi corrigido ao descompactar um arquivo .lzh depois de descompactar um arquivo .Z". Estouro de buffer significa que o programa escreve além da memória que reservou.

As outras duas geram saída errada em vez de travar. Descompactar um arquivo .lzh logo após outro podia corromper o resultado, porque a tabela de decodificação do arquivo anterior continuava no lugar. A saída também podia ser corrompida quando um buffer de bits interno não era limpo corretamente.

À parte disso, a versão corrige "um uso de memória não inicializada em algumas entradas malformadas". Trata-se de memória lida antes de qualquer coisa ter sido escrita nela.

O anúncio não cita nenhum identificador CVE para esses pontos.

O que mais mudou

Algumas mudanças alteram o comportamento em vez de corrigir um defeito, e algumas plataformas antigas ficaram de fora.

Mudança	O que significa
Tratamento de locale	O gzip segue o locale do ambiente em vez de assumir o locale C
Taxa de arquivos vazios	Um arquivo vazio agora informa -Inf% em vez de 0.0%
znew -P	A opção é ignorada e emite um aviso
Diagnósticos	Nomes de arquivo com caracteres incomuns aparecem entre aspas
Fluxos PKZIP	gzip -d aceita assinaturas PKZIP, cabeçalhos locais e descritores de dados
Plataformas removidas	FreeBSD 4.11 e anteriores, HP-UX 11.00, Minix 3.1.8, Windows 8.1 via MinGW sem UCRT

As corridas por arquivos temporários nos scripts gzexe, zdiff e znew também foram corrigidas.

O que isso significa para desenvolvedores

Trate esta versão como uma atualização de segurança, mesmo sem CVE. Duas das correções são falhas de segurança de memória no decodificador. Se algum serviço seu entrega ao gzip arquivos vindos de terceiros, esse decodificador é alcançável de fora. Nesse caso, ele merece um lugar na frente da fila de correções. A Rustls mostrou o mesmo ponto ao corrigir uma falha de TLS 1.3 aberta desde 2024: idade não é prova de que uma falha seja inofensiva.

Verifique dois pontos específicos nos seus scripts antes de atualizar. Se algo analisa a taxa de compressão do gzip, o caso do arquivo vazio agora imprime -Inf% e um analisador que espera um número simples vai quebrar. Se algo depende de o gzip ordenar ou exibir nomes de arquivo do mesmo jeito em toda parte, a mudança de locale pode deslocar esse resultado entre máquinas.

A corrida de exclusão merece atenção se você roda o gzip onde diretórios são renomeados sob ele. Scripts de implantação que trocam uma pasta de release são a forma comum disso. A janela é pequena, mas o custo de perder o arquivo errado não é.

Por fim, confira as plataformas removidas antes de atualizar uma imagem de build. Se você ainda compila para HP-UX 11.00 ou para Windows 8.1 via MinGW sem UCRT, o gzip 1.15 é onde esse caminho termina.