Gzip 1.15 fixes decades-old race that could delete the wrong file

The GNU project released gzip 1.15 on September 20, 2026, closing a batch of defects that in many cases have been present since the compression utility's earliest days. Jim Meyering announced the release on the GNU info-gnu mailing list. The headline fix removes a race condition that could make gzip delete a file it never intended to touch.

The release accumulates 119 commits written over 75 weeks, with Paul Eggert contributing 88 and Meyering 24, alongside smaller sets from Mark Adler, Bruno Haible and Collin Funk. According to Phoronix, the prior release, gzip 1.14, dates to April 2025.

How the wrong-file deletion happened

Gzip's standard workflow is to compress a file and then remove the original once the compressed output is safely written. The flaw lived in that final step, in working out which file to unlink.

According to the announcement, if another process renames a directory above gzip's output path while gzip is mid-operation, gzip can resolve the path a second time and land on a different file, which it then deletes. An ancestor here means any directory higher up the path than the target file.

Because the failure depends on the timing of two independent programs, it needs a precise coincidence and is therefore rare. On busy servers running concurrent automation, though, rare is not the same as never, and Tech AI Wire points to deployment scripts that swap release folders into place as the classic trigger: they rename directories underneath processes still working inside them.

A second synchronization fix addresses locking failures on systems that support the O_PATH or O_SEARCH flags. That bug is younger than the rest, having arrived with gzip 1.7.

Memory-safety fixes in the .lzh decoder

Three of the fixes target gzip's decoder for .lzh files, a legacy compression format that saw heavy use in Japan. The announcement reports a buffer overflow reachable when decompressing an .lzh file after decompressing a .Z file, meaning the program could write past the end of the memory it reserved.

Two further .lzh defects produced corrupted output rather than a crash: decompressing one .lzh file after another could reuse a stale decoding table left over from the previous file, and an internal bit buffer could be left uncleared. Separately, gzip could read uninitialized memory on some malformed inputs. The announcement lists no CVE identifiers for any of these issues.

Behavior changes and dropped platforms

Several changes alter behavior rather than repair defects, and a few deserve a quick audit before upgrading:

• Gzip now follows the environment's locale instead of assuming the C locale, which can change how file names are sorted or reported between machines.
• Compressing an empty file now reports a ratio of -Inf% instead of 0.0%, which will break any script that parses the ratio as a plain number.
• The znew -P option is now ignored and prints a warning.
• Diagnostic messages now quote file names containing unusual characters.
• gzip -d now accepts PKZIP signatures, local headers and data descriptors.

Support was dropped for FreeBSD 4.11 and earlier, HP-UX 11.00, Minix 3.1.8, and Windows 8.1 builds via MinGW without UCRT. Races around temporary files in the gzexe, zdiff and znew helper scripts were also fixed.

Why it matters

Gzip is the engine behind the .gz files that ship with almost every Linux and Unix system, and it is wired into package managers, backup jobs and log rotation. A defect in such low-profile but ubiquitous plumbing reaches far more machines than its profile suggests, and scripts have been running on top of these bugs for decades.

The deletion race is a data-loss bug, not merely a crash: when it fires, the wrong file is gone. The decoder fixes deserve attention too. Even without CVE identifiers, two are memory-safety bugs, and any service that feeds attacker-supplied archives to gzip exposes that decoder to untrusted input. The practical checklist is short: patch, check anything that parses gzip's ratio output or relies on locale-stable file-name handling, review deployment scripts that rename directories under running jobs, and confirm your build targets are not among the dropped platforms.