gzip 1.15、誤ったファイルを削除する競合状態を修正

gzip 1.15が2026年9月20日に公開された。gzipが誤ったファイルを削除しうる不具合を修正している。Jim Meyering氏がGNUのinfo-gnuメーリングリストでリリースを告知した。修正された不具合の多くは、gzipの最初期から存在していた。つまりスクリプトは何十年もその上で動いてきたことになる。

gzipは、ほぼすべてのLinuxとUnixに付属する.gzファイルを扱う圧縮プログラムだ。パッケージマネージャ、バックアップ処理、ログローテーションに組み込まれている。目立たない存在だが、その欠陥は見た目よりはるかに多くのマシンに届く。

今回のリリースは75週間で書かれた119件のコミットを含む。Paul Eggert氏が88件、Meyering氏が24件を担当し、Mark Adler氏、Bruno Haible氏、Collin Funk氏がそれぞれ少数を寄せた。Phoronixによれば、前回のリリースであるgzip 1.14は2025年4月に公開された。

削除の不具合が引き起こしていたこと

gzipは通常、ファイルを圧縮したあとに元のファイルを削除する。どのファイルを削除するかを判断する部分に、この不具合があった。

告知は修正内容をはっきり記している。「他のプロセスがgzipの出力先の祖先ディレクトリを同時にリネームした場合でも、gzipが誤ったファイルを削除することはなくなった」。ここでいう祖先とは、対象ファイルより上位にあるディレクトリのことだ。

つまり危険が生じるのは、2つのことが同時に起きたときだ。gzipが処理の途中にあり、別のプロセスがパス上のフォルダをリネームする。gzipはパスを解決し直し、開始時とは別のファイルにたどり着きうる。

これは競合状態と呼ばれる。2つの別々のプログラムのタイミング次第で結果が変わる、という意味だ。そのタイミングが揃う必要があるため、発生はまれである。ただし自動処理が走り続けるサーバーでは、まれと決してないは同じではない。

ロックに関する2つ目の問題も修正された。O_PATHやO_SEARCHというファイルフラグに対応したシステムで、同期が失敗することがあった。これだけは他より新しく、gzip 1.7で入り込んだものだ。

.lzh展開における3つの破損修正

gzipは今でも.lzhファイルを読める。これは日本で広く使われた古い圧縮形式だ。修正のうち3件はそのデコーダにある。

1つはメモリ安全性の修正だ。告知は「.Zファイルを展開した後に.lzhファイルを展開する際のバッファオーバーフローを修正した」と報告している。バッファオーバーフローとは、確保したメモリの終端を越えて書き込んでしまうことをいう。

残る2つはクラッシュではなく、誤った出力を生む。.lzhファイルを続けて展開すると、前のファイルのデコードテーブルが残り、結果が壊れることがあった。内部のビットバッファが正しくクリアされない場合にも出力が壊れうる。

これとは別に、「一部の不正な入力における未初期化メモリの使用」も修正された。これは、何も書き込まれる前に読み出されるメモリのことだ。

告知には、これらに対するCVE識別子は一切記載されていない。

その他の変更点

不具合の修正ではなく挙動を変える変更もあり、いくつかの古いプラットフォームは対象から外れた。

変更	内容
ロケールの扱い	Cロケールを前提とせず、環境のロケールに従うようになった
空ファイルの圧縮率	空ファイルの圧縮率が0.0%ではなく-Inf%と表示される
znew -P	このオプションは無視され、警告が出るようになった
診断メッセージ	珍しい文字を含むファイル名が引用符で囲まれる
PKZIPストリーム	gzip -dがPKZIPの署名、ローカルヘッダ、データ記述子を受け付ける
対象外となった環境	FreeBSD 4.11以前、HP-UX 11.00、Minix 3.1.8、UCRTなしのMinGWによるWindows 8.1

gzexe、zdiff、znewという補助スクリプトの一時ファイル競合も修正された。

開発者にとっての意味

CVEが付いていなくても、これはセキュリティ更新として扱うべきだ。修正のうち2件は、デコーダにおけるメモリ安全性の不具合である。攻撃者が用意したアーカイブをgzipに渡すサービスを運用しているなら、そのデコーダは外部から到達可能だ。適用の優先度は高く置いてよい。Rustlsが2024年から残っていたTLS 1.3の欠陥を修正したときも、同じ点が示された。古いことは、その不具合が無害である証拠にはならない。

更新の前に、スクリプトの2点を確認してほしい。gzipの圧縮率の出力を解析している箇所があるなら、空ファイルの場合は-Inf%と表示される。単なる数値を期待するパーサーは壊れる。ファイル名の並びや表示がどの環境でも同じであることに依存している箇所があるなら、ロケールの変更でマシンごとに結果がずれうる。

削除の競合状態は、ディレクトリがgzipの足元でリネームされる環境なら確認しておく価値がある。リリース用フォルダを差し替えるデプロイスクリプトが、その典型的な形だ。発生の窓は小さいが、誤ったファイルを失う代償は小さくない。

最後に、ビルドイメージを更新する前に対象外となったプラットフォームを確認してほしい。HP-UX 11.00向けや、UCRTなしのMinGWによるWindows 8.1向けにまだコンパイルしているなら、gzip 1.15がその終点になる。