Linux

Copy Fail続報、パッチなき開示で世界が混乱

公開済みエクスプロイトに対し、主要ディストリビューションのパッチ済みカーネルが揃っていない。Theoriの開示プロセスが「ゼロデイ・パッチギャップ」を生んだとの批判が広がっている。

情報の灯台

2026年5月1日

エクスプロイトはあるのにパッチがない、という現実

Linuxカーネルの権限昇格脆弱性「Copy Fail」（CVE-2026-31431）は、公開から2日が経ったいまも、ほぼすべての主要ディストリビューションでパッチ済みカーネルパッケージが出荷されていない。Ars Technicaのダン・グッディン(Dan Goodin)記者がこの状況を「世界がスクランブル状態に陥っている」と報じている。

Theori社の研究者がこの脆弱性とエクスプロイトコードを公開したのは2026年4月29日（米国時間）。アップストリームへの修正コミットは4月1日に取り込まれており、Linux 7.0、6.19.12、6.18.22などのStable系列に反映されている。問題はそこから先だ。修正はあるのに、ユーザーの手元に届いていない。

EUのコンピュータ緊急対応チームCERT-EUは4月30日付の勧告で、状況をはっきり書いた。「本勧告日時点で、いかなるディストリビューションも修正済みカーネルパッケージを出荷していない。」例外的に動けたのはローリングリリース勢で、Ars TechnicaはArch LinuxとFedoraがパッチを当てた状態にあると伝えている。Arch Linuxは設計上、メインラインのStableリリースをほぼ即座に取り込むため、Linux 7.0などの修正済みバージョンが利用者の手元に行き渡っている。一方UbuntuのCanonicalはLivePatchによる自動配信の準備を進め、Red Hat Enterprise Linuxはステータスを「Fix deferred(修正延期)」のままにしている。

Tharros社の主任脆弱性アナリスト、ウィル・ドーマン(Will Dormann)は厳しい。「開示を行った組織は、脆弱性協調(coordination)の仕事として絶対的にひどい仕事をした。」インタビューで彼はこう語った。「私を困惑させるのは、彼らの記事のなかでA)影響を受けるベンダー4社をリストアップし、B)読者にベンダーパッチの適用を促していることだ。にもかかわらず、リストアップしたベンダーのうちひとつでも実際にパッチを持っているか、公開前に確認しなかった（誰も持っていない）」

ベンダー4社をリストアップして「パッチを当てろ」と書きながら、その4社のうち誰一人パッチを出していない、というドーマンの指摘は重い。読者は記事を読み、リンクをたどり、そこにあるはずの修正パッケージを探す。見つからない。エクスプロイトコードだけが、いま現在世界中のサーバーで稼働している。

「ゼロデイパッチギャップ」という新しい現実

セキュリティ研究の世界には「ゼロデイ」「N-day」という線引きがあった。修正前に公開されればゼロデイ、修正後ならN-day。Copy Failはそのどちらにも収まりきらない、いびつな位置にいる。

メインラインのカーネルでは修正されている。だがユーザーの環境にはまだ届いていない。グッディンはこの状況を「ゼロデイ脆弱性が投下されたのと非常によく似ている、ただしゼロデイ・パッチギャップという、より厳しい用語のほうが適切だろう」と表現した。事実上のゼロデイだが、その原因は技術的な未解決ではなく、情報伝達の断絶にある。

Theoriが開示の締切に向けてLinuxカーネルセキュリティチームには連絡したものの、ディストリビューターには連絡を取った形跡がない、とArs Technicaは独自に指摘している。Linuxカーネル開発の現場とディストリビューションのメンテナはチームが分かれていて、メインラインの修正が各ディストロのカーネルパッケージに反映されるまでにはバックポート作業がいる。その時間を見越して、責任ある開示は通常、ディストリビューターにも事前通知を行う。

修正済みディストリビューションが揃う前にエクスプロイトが利用可能になれば、開示は実質的にゼロデイ投下と何ら変わらない。Linuxディストリビューターは古いカーネルバージョンに留まって修正をバックポートする運用を取ることが多く、その猶予をTheoriは与えなかった、というのがArs Technicaの読みだ。

「協調プロセスのひどさは、Theoriの研究品質とは独立した問題だ」とドーマンは言う。「彼らは技術的には素晴らしい仕事をした。バグを見つけ、書き上げ、再現可能なエクスプロイトを構築した。しかし、開示の運用がそれを台無しにしている。」

バグを見つけた手腕と、それを伝える運用の精度が、ここまで噛み合わない事例も珍しい。AIで脆弱性発見のコストが下がる時代に、開示の側がついていっていないと言ってもいい。

「緩和策が機能しない」というもう一つの罠

事態をさらに複雑にしているのは、Theoriが推奨する暫定緩和策が、相当数の環境でそもそも動かないことだ。

CloudLinuxは公式ブログで明確に警告を出した。/etc/modprobe.d/にinstall algif_aead /bin/falseを書き込み、rmmod algif_aeadを叩くという推奨手順が、CloudLinux、AlmaLinux、その他RHEL系ディストリビューションでは効かない。algif_aeadがカーネルに静的にビルトインされており（CONFIG_CRYPTO_USER_API_AEAD=y）、modprobeのルールではロードを阻止できないし、rmmodでも除去できないのが理由だ。

「コマンドはエラーなく走るが、システムの状態は変わらない。実行すれば保護されたという誤った安心感を与えるだけだ」とCloudLinuxは記している。

これが意味するのは、エンタープライズLinuxの主要セグメントが、推奨緩和策の枠外に置かれているということだ。RHEL、AlmaLinux、Rocky Linux、CloudLinux――HostingやCI、Kubernetesノードで多用される系列が、「対策があるように見えて実際にはない」状態にある。確認するにはgrep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)を実行し、=yなら静的ビルトイン、=mならモジュール分離。前者の場合、カーネルパッケージのアップデートを待つ以外の選択肢はほぼない。

Ubuntuの場合は事情が違う。CanonicalはLivePatch経由でカーネル外の緩和策（kmodパッケージのアップデートでalgif_aeadの使用を阻止する）を配布する仕組みを発表した。Ubuntu 26.04（Resolute）以降は影響を受けないことも明示している。ディストリビューションごとに対応の精度が大きく違うのは、コミュニティの運用文化の差がそのまま出ている。

なぜ4月29日に公開する必要があったのか

ここで一度立ち止まる価値がある。3月23日に通知して4月1日にメインライン修正、そして4月29日に公開という時系列は、責任ある開示としては短くない。Theoriの主張する「彼らはやるべきことをやった」という立場には、それなりの正当性がある。

ただ、Linuxエコシステムの現実として、4月1日にメインラインに入った修正がディストロのStableカーネルパッケージに行き渡るには、通常数週間から数ヶ月かかる。Red HatのCVEページがCVE-2026-31431を「Moderate」「Fix deferred」と表示しているのは、彼らの通常のSLAに沿った判断であって、サボタージュではない。

問題は、Theori側がそのリードタイムを織り込まなかったことだ。あるいは、織り込んだうえで「待たない」と決めたことだ。後者であれば、それは1つの判断であり、批判の対象になりうる。前者であれば、それは責任ある開示の運用に対する理解の浅さを示している。

Bugcrowdの最高AI・科学責任者、デビッド・ブラムリー(David Brumley)は、Copy Fail公開時の論評でこう書いた。「VDP（脆弱性開示プログラム）と開示パイプラインは、いまや負荷を支える構造材になった。ソフトウェアを出荷するすべての組織は、より広い母集団から信頼できる報告を高い到着レートで受け止められる、協調的な開示の受け口を持つ必要がある。」

ここで言われているのは、ディストリビューター側の準備不足でもある。だがそれは同時に、開示する側がディストリビューターと協働する責任でもある。AIで脆弱性発見のコストが桁違いに下がるなら、開示プロセスの設計はそれに追いつかなければならない。Copy Failは、その追いつきが間に合っていない瞬間を切り取った事案だ。

いまユーザーに残されている選択肢

ベンダーのカーネルパッチを待つあいだ、現実的に取れる動きは限られている。

第一に、algif_aeadがモジュールとしてビルドされている環境（Debian系の多くがこれに該当する）では、推奨されたmodprobe無効化が有効に働く。lsof | grep AF_ALGで実際の利用状況を確認し、依存しているプロセスがなければ無効化を進めてよい。dm-crypt/LUKS、kTLS、OpenSSL、GnuTLS、SSHなどには影響しない、とCERT-EUは明記している。

第二に、RHEL系のように静的ビルトイン環境では、Sysdigなどが公開している検出ルールを参考に、AF_ALG SEQPACKETソケットを開くプロセスを監視するのが現実的な防衛線になる。cryptsetupやsystemd-cryptsetupなど正規のディスク暗号化ツール以外がこのソケットを開いていれば、Copy Failの第一歩と疑ってよい。

第三に、優先度の付け方を間違えないこと。マルチテナントLinuxホスト、Kubernetesノード、信頼できないコードを動かすCIランナー、ユーザーコードを実行するクラウド SaaSが最優先だ。シングルユーザーのワークステーションは後回しでよい。脅威モデルが「ローカルユーザーが他のユーザーのコードと隣り合っているか」で決まるためだ。