Gzip 1.15 corrige una carrera que borraba el archivo equivocado

Gzip 1.15 se publicó el 20 de septiembre de 2026 y corrige un fallo que podía hacer que gzip borrara el archivo equivocado. Jim Meyering anunció la versión en la lista de correo info-gnu de GNU. La mayoría de los fallos corregidos están en gzip desde sus inicios. Es decir, hay scripts que llevan décadas ejecutándose sobre ellos.

Gzip es el programa de compresión detrás de los archivos .gz que acompañan a casi todos los sistemas Linux y Unix. Está integrado en gestores de paquetes, copias de seguridad y rotación de registros. Un defecto en él alcanza muchas más máquinas de lo que sugiere su bajo perfil.

Esta versión incluye 119 commits escritos a lo largo de 75 semanas. Paul Eggert aportó 88 y Meyering 24, con contribuciones menores de Mark Adler, Bruno Haible y Collin Funk. La versión anterior, gzip 1.14, salió en abril de 2025 según Phoronix.

Qué hacía el fallo de borrado

Gzip normalmente comprime un archivo y después elimina el original. El fallo estaba justo en determinar qué archivo eliminar.

El anuncio expone la corrección con claridad: «gzip ya no puede eliminar por error el archivo equivocado si otro proceso renombra simultáneamente un directorio ancestro del destino de gzip». Un ancestro es aquí cualquier directorio por encima del archivo de destino.

El peligro aparece, por tanto, cuando ocurren dos cosas a la vez. Gzip está a mitad de su trabajo y otro proceso renombra una carpeta de la ruta. Gzip resuelve la ruta de nuevo y puede acabar en un archivo distinto del inicial.

Esto es una condición de carrera, o race condition. El resultado depende de cómo coincidan en el tiempo dos programas separados. Como esa coincidencia es necesaria, el caso es raro. En un servidor con muchas tareas automáticas, raro no significa nunca.

También se corrigió un segundo problema de bloqueo. La sincronización podía fallar en sistemas que admiten las banderas de archivo O_PATH u O_SEARCH. Ese es más reciente que el resto: llegó con gzip 1.7.

Tres correcciones en la decodificación .lzh

Gzip todavía lee archivos .lzh, un formato de compresión antiguo muy usado en Japón. Tres de las correcciones están en ese decodificador.

Una es de seguridad de memoria. El anuncio indica que «se ha corregido un desbordamiento de búfer al descomprimir un archivo .lzh después de descomprimir un archivo .Z». Un desbordamiento de búfer significa que el programa escribe más allá de la memoria que reservó.

Las otras dos producen una salida incorrecta en lugar de un fallo grave. Descomprimir un archivo .lzh justo después de otro podía corromper el resultado, porque seguía en su sitio la tabla de decodificación del archivo anterior. La salida también podía corromperse cuando un búfer de bits interno no se vaciaba correctamente.

Aparte, la versión corrige «un uso de memoria no inicializada con algunas entradas mal formadas». Se trata de memoria que se lee antes de haber escrito nada en ella.

El anuncio no menciona ningún identificador CVE para estos puntos.

Qué más ha cambiado

Algunos cambios alteran el comportamiento en lugar de corregir un defecto, y unas cuantas plataformas antiguas quedan fuera.

Cambio	Qué significa
Manejo de la configuración regional	Gzip sigue la locale del entorno en vez de suponer la locale C
Ratio de archivos vacíos	Un archivo vacío ahora informa -Inf% en lugar de 0.0%
znew -P	La opción se ignora y muestra una advertencia
Diagnósticos	Los nombres de archivo con caracteres inusuales se entrecomillan
Flujos PKZIP	gzip -d acepta firmas PKZIP, cabeceras locales y descriptores de datos
Plataformas retiradas	FreeBSD 4.11 y anteriores, HP-UX 11.00, Minix 3.1.8, Windows 8.1 vía MinGW sin UCRT

También se corrigieron las carreras de archivos temporales en los scripts auxiliares gzexe, zdiff y znew.

Qué significa esto para los desarrolladores

Trate esta versión como una actualización de seguridad aunque no lleve CVE. Dos de las correcciones son fallos de seguridad de memoria en el decodificador. Si algún servicio suyo pasa a gzip archivos suministrados por terceros, ese decodificador es alcanzable desde fuera. En ese caso conviene ponerlo al principio de la cola de parches. Rustls dejó clara la misma idea al corregir un fallo de TLS 1.3 abierto desde 2024: la antigüedad no prueba que un fallo sea inofensivo.

Revise dos cosas concretas en sus scripts antes de actualizar. Si algo analiza la salida del ratio de compresión de gzip, el caso del archivo vacío ahora imprime -Inf% y un analizador que espere un número simple fallará. Si algo depende de que gzip ordene o muestre los nombres de archivo igual en todas partes, el cambio de locale puede desplazar ese resultado entre máquinas.

La carrera de borrado merece una revisión si ejecuta gzip donde se renombran directorios bajo él. Los scripts de despliegue que intercambian una carpeta de versión son su forma habitual. La ventana es pequeña, pero el coste de perder el archivo equivocado no lo es.

Por último, revise las plataformas retiradas antes de actualizar una imagen de compilación. Si todavía compila para HP-UX 11.00 o para Windows 8.1 vía MinGW sin UCRT, gzip 1.15 es donde termina ese camino.