Gzip 1.15 behebt Wettlauf beim Löschen falscher Dateien

Gzip 1.15 erschien am 20. September 2026 und behebt einen Fehler, durch den gzip die falsche Datei löschen konnte. Jim Meyering kündigte die Version auf der GNU-Mailingliste info-gnu an. Die meisten der behobenen Fehler stecken seit den Anfängen in gzip. Skripte laufen also seit Jahrzehnten auf dieser Grundlage.

Gzip ist das Komprimierungsprogramm hinter den .gz-Dateien, die fast jedes Linux- und Unix-System mitbringt. Es steckt in Paketmanagern, Backup-Jobs und der Logrotation. Ein Fehler darin erreicht weit mehr Maschinen, als seine geringe Sichtbarkeit vermuten lässt.

Die Version umfasst 119 Commits aus 75 Wochen Arbeit. Paul Eggert steuerte 88 davon bei, Meyering 24, dazu kommen kleinere Beiträge von Mark Adler, Bruno Haible und Collin Funk. Die vorherige Version, gzip 1.14, erschien laut Phoronix im April 2025.

Was der Löschfehler anrichtete

Gzip komprimiert normalerweise eine Datei und entfernt danach das Original. Genau bei der Frage, welche Datei zu entfernen ist, saß dieser Fehler.

Die Ankündigung benennt die Korrektur klar: "gzip kann nicht mehr fälschlich die falsche Datei entfernen, wenn ein anderer Prozess gleichzeitig ein übergeordnetes Verzeichnis des gzip-Ziels umbenennt." Übergeordnet meint hier jedes Verzeichnis oberhalb der Zieldatei.

Die Gefahr entsteht also, wenn zwei Dinge gleichzeitig passieren. Gzip ist mitten in der Arbeit, und ein anderer Prozess benennt einen Ordner im Pfad um. Gzip löst den Pfad erneut auf und kann bei einer anderen Datei landen als zu Beginn.

Das ist ein Wettlauf, englisch race condition. Das Ergebnis hängt also vom zeitlichen Zusammentreffen zweier getrennter Programme ab. Weil dieses Zusammentreffen nötig ist, kommt es selten vor. Auf einem Server mit vielen automatischen Jobs ist selten aber nicht dasselbe wie nie.

Ein zweites Problem mit Sperren wurde ebenfalls behoben. Auf Systemen mit den Dateiflags O_PATH oder O_SEARCH konnte die Synchronisierung fehlschlagen. Dieser Fehler ist jünger als die übrigen: Er kam mit gzip 1.7.

Drei Korrekturen beim Entpacken von .lzh

Gzip liest weiterhin .lzh-Dateien, ein älteres Komprimierungsformat, das vor allem in Japan verbreitet war. Drei der Korrekturen betreffen diesen Decoder.

Eine davon betrifft die Speichersicherheit. Die Ankündigung meldet: "Ein Pufferüberlauf wurde behoben, der beim Entpacken einer .lzh-Datei nach dem Entpacken einer .Z-Datei auftrat." Ein Pufferüberlauf bedeutet, dass das Programm über das Ende des reservierten Speichers hinaus schreibt.

Die beiden anderen führen nicht zum Absturz, sondern zu falscher Ausgabe. Wurde eine .lzh-Datei direkt nach einer anderen entpackt, konnte die Dekodiertabelle der vorherigen Datei das Ergebnis beschädigen. Auch ein nicht korrekt geleerter interner Bitpuffer konnte die Ausgabe verfälschen.

Zusätzlich behebt die Version "die Verwendung nicht initialisierten Speichers bei einigen fehlerhaften Eingaben." Gemeint ist Speicher, der gelesen wird, bevor etwas hineingeschrieben wurde.

Die Ankündigung nennt zu keinem dieser Punkte eine CVE-Kennung.

Was sich sonst geändert hat

Einige Änderungen ändern das Verhalten, statt einen Fehler zu beheben. Ein paar alte Plattformen fallen weg.

Änderung	Bedeutung
Locale-Behandlung	Gzip folgt der Locale der Umgebung, statt die C-Locale anzunehmen
Rate bei leeren Dateien	Eine leere Datei meldet jetzt -Inf% statt 0.0%
znew -P	Die Option wird ignoriert und gibt eine Warnung aus
Diagnosemeldungen	Dateinamen mit ungewöhnlichen Zeichen werden in Anführungszeichen gesetzt
PKZIP-Ströme	gzip -d akzeptiert PKZIP-Signaturen, lokale Header und Data Descriptors
Entfallene Plattformen	FreeBSD 4.11 und älter, HP-UX 11.00, Minix 3.1.8, Windows 8.1 über MinGW ohne UCRT

Auch Wettläufe bei temporären Dateien in den Hilfsskripten gzexe, zdiff und znew wurden behoben.

Was das für Entwickler bedeutet

Behandeln Sie das als Sicherheitsupdate, auch ohne CVE. Zwei der Korrekturen sind Fehler der Speichersicherheit im Decoder. Wenn ein Dienst von Ihnen gzip mit Archiven aus fremder Hand füttert, ist dieser Decoder von außen erreichbar. Dann gehört das Update weit nach vorn in die Warteschlange. Rustls machte denselben Punkt, als es kürzlich einen seit 2024 offenen TLS-1.3-Fehler behob: Alter ist kein Beleg dafür, dass ein Fehler harmlos ist.

Prüfen Sie vor dem Update zwei Dinge in Ihren Skripten. Wertet etwas die Kompressionsrate von gzip aus, steht bei leeren Dateien nun -Inf%. Ein Parser, der eine schlichte Zahl erwartet, bricht daran. Verlässt sich etwas darauf, dass gzip Dateinamen überall gleich sortiert oder ausgibt, kann die Locale-Änderung dieses Ergebnis je nach Maschine verschieben.

Der Löschfehler lohnt einen Blick, wenn gzip dort läuft, wo Verzeichnisse unter ihm umbenannt werden. Deployment-Skripte, die einen Release-Ordner austauschen, sind die übliche Form davon. Das Zeitfenster ist klein, der Preis für eine verlorene falsche Datei ist es nicht.

Prüfen Sie zuletzt die entfallenen Plattformen, bevor Sie ein Build-Image aktualisieren. Wer noch für HP-UX 11.00 oder für Windows 8.1 über MinGW ohne UCRT kompiliert, findet in gzip 1.15 das Ende dieses Wegs.