Linuxを732バイトで陥落、9年潜むCopy Fail
2017年以降のほぼ全Linuxディストロが、たった732バイトのPythonでrootを奪われる脆弱性を抱えていた。9年間誰も気づかなかったバグを、AIスキャンが約1時間で釣り上げた事案だ。
2017年以降のほぼ全Linuxディストロが、たった732バイトのPythonでrootを奪われる脆弱性を抱えていた。9年間誰も気づかなかったバグを、AIスキャンが約1時間で釣り上げた事案だ。
たった732バイトで全主要ディストロが屈する
Theori社のXint Codeチームが「Copy Fail（CVE-2026-31431）」と名付けたLinuxカーネルの脆弱性を、2026年4月29日に公開した。Linuxカーネルのcryptoサブシステムに潜む論理バグで、非特権の一般ユーザーがrootを取得できる。報告先のLinuxカーネルセキュリティチームは3月23日に通知を受け、4月1日にメインラインへの修正コミットを取り込んでいる。
衝撃的なのは、その規模だ。Ubuntu 24.04 LTS、Amazon Linux 2023、RHEL 10.1、SUSE 16の4つで、同一スクリプトが無修正で動く。アーキテクチャ別の調整も、カーネルバージョン別のオフセット指定も不要。標準ライブラリ（os、socket、zlib）のみで構成され、Python 3.10以上があれば走る。
過去の有名なLinuxローカル権限昇格脆弱性、たとえばDirty Cow（CVE-2016-5195）は仮想メモリのコピーオンライト経路でレースコンディションを勝ち取る必要があり、何度も試行を要した。Dirty Pipe（CVE-2022-0847）はカーネルバージョン依存で、パイプバッファの精密な操作が必要だった。
Copy Failは、そのどちらも要らない。レース勝負も、リトライも、タイミングウィンドウも不要な、直線的な論理の欠陥だ。
Bugcrowdの最高AI・科学責任者であるデビッド・ブラムリー(David Brumley)は、「Copy Failは別のサブシステムに存在する、Dirty Pipeと同じクラスの脆弱性プリミティブだ。algif_aeadに2017年に入ったin-place最適化が、AEAD操作のためのページキャッシュページをカーネルの書き込み可能なスキャッタリストに送り込んでしまう」とコメントしている。
「ページキャッシュへの4バイト書き込み」が意味するもの
技術的な核心はシンプルだ。一般ユーザーが、自分が読み取り権限を持つ任意のファイルのページキャッシュに、制御された4バイトを書き込める。
ページキャッシュ（page cache）とは、Linuxがファイルをメモリ上にキャッシュしておく仕組みだ。プロセスがファイルを読むときも、カーネルがバイナリを実行するために読み込むときも、まずこのキャッシュが参照される。ディスク上のファイルは変わらないのに、システム全体から見える「読まれる中身」だけが書き換わる。
攻撃者は /usr/bin/su のようなsetuid-rootバイナリを狙う。ページキャッシュ上のsuのコードに、自分のシェルコードを4バイトずつ書き込んでいき、最後に execve("/usr/bin/su") を叩く。カーネルはキャッシュされた汚染版を読んで実行し、setuid属性により改ざんされたコードがUID 0、つまりrootとして走る。
ディスク上のファイルは無傷なので、tripwireやAIDEのような従来型のファイル整合性チェックツールは検知できない。書き込みフラグも立たないため、inotify 系の監視も素通りする。
Theori研究者のテヤン・リー(Taeyang Lee)による解説では、攻撃者は「どのファイルに」「どのオフセットで」「どんな値を」書き込むかをすべて制御できるとされている。書き込み値はAEADのシーケンス番号低位（seqno_lo）として、攻撃者がsendmsg()で構築する8バイトの関連認証データに由来する。
9年間検出されなかった理由は「合理的な意思決定の交差点」
Copy Failを成立させているのは、それぞれ単独では問題のない3つの変更だ。
最初のピースは2011年にさかのぼる。IPsec ESPの64ビット拡張シーケンス番号（RFC 4303）をサポートするため、authencesn というAEADテンプレートが追加された。このコードは当初から、呼び出し元の宛先スキャッタリストを「ESNバイトの並び替え用のスクラッチ領域」として使っていた。当時の唯一の利用者はカーネル内部のxfrm層で、関連認証データは別のスキャッタリストに置かれていたから、書き込みが境界をまたぐことはなかった。
2015年、AF_ALGにAEAD対応が入り、splice() 経由でページキャッシュページがcryptoスキャッタリストに渡る経路が開いた。同年、authencesnも新しいAEADインターフェースに移行している。ただこの時点ではAF_ALGはout-of-place動作で、入力（src）と出力（dst）のスキャッタリストが分離されていた。ページキャッシュページは読み取り側にあり、authencesnのスクラッチ書き込みはユーザーバッファ側のdstに着地していた。まだ刺さらなかった。
そして2017年、algif_aead.cにin-place最適化が入った（コミット72548b093ee3）。AEAD操作で req->src = req->dst と同じスキャッタリストを共有させ、認証タグ部分は sg_chain() でページキャッシュページを書き込み可能な宛先側に連鎖させる構造になった。
この瞬間、3つのピースが揃った。authencesnのスクラッチ書きが、splice()で持ち込まれたページキャッシュページに着弾するようになった。
Theoriの研究者によるまとめは、こう記している。
誰も2017年のin-place最適化と、authencesnのスクラッチ書きと、splice()のページキャッシュ起源を結び付けなかった。それぞれの変更は単独では合理的だった。脆弱性はすべての交差点に存在し、ほぼ10年間、静かに悪用可能だった。
セキュリティの欠陥は、しばしば単一の悪い意思決定からは生まれない。それぞれ正しい判断が、別々の時間軸で積み重なり、誰も全体を見渡さないまま交差点を作る。Copy Failはそのパターンの教科書のような事例だ。
AIが約1時間で発見したという事実が持つ意味
もう一つ、この脆弱性のインパクトを決定づける要素がある。発見方法だ。
Theoriの研究者、テヤン・リーは、AF_ALGとsplice()の組み合わせから、スキャッタリストにページキャッシュページが流れ込む経路があると見当をつけていた。彼はその仮説を、Theoriが開発するAI支援セキュリティ解析ツール「Xint Code」に渡した。
オペレータープロンプトはほぼ一文だった。「これはLinuxのcrypto/サブシステム。ユーザー空間のシステムコールから到達可能なすべての経路を調査せよ。splice()は読み取り専用ファイル（setuidバイナリを含む）のページキャッシュ参照をcrypto TXスキャッタリストへ届けうることに留意せよ」。
スキャンは約1時間で完了し、Copy Failは最高深刻度の出力として上がってきた。同じスキャンでは他にも複数の高深刻度の脆弱性が見つかっており、現在も責任ある開示プロセスが進行中だという。
Theoriはセキュリティ業界で実績のあるチームだ。CMUのPPP、UBCのMaple BaconとともにMMMチームを組み、DEF CON CTFで9度の優勝を果たし、DARPA AI Cyber Challengeの決勝でも3位入賞している。彼らが「ワンプロンプトで1時間」と言うとき、それは比喩ではない可能性が高い。
ここで考えるべきは、Copy Failそのものよりも、それが約1時間で見つかったという事実のほうかもしれない。深いロジック欠陥を発見するコストが、桁違いに下がっている可能性がある。同じ手法を、攻撃者側もすでに走らせていると考えるべきだろう。
影響範囲とコンテナの脅威モデル
Copy Failの威力を本当に怖くしているのは、コンテナ境界を越えることだ。ページキャッシュはホスト全体で共有されている。コンテナ内の非特権ユーザーが、ホスト側のsetuidバイナリのページキャッシュを書き換えられる。
Theoriは2部構成のうち第1部としてローカル権限昇格を公開しており、第2部ではKubernetesのノード侵害ベクトルとしての影響を扱う予定だ。「コンテナで隔離してあるから安全」という、過去10年のクラウドネイティブが頼ってきた防御モデルに、正面から圧力がかかる事案になる。
CVSS 3.1スコアは7.8（High）と評価されている。ただ、リアルなリスクはこのスコアが暗示する以上に大きい。第三者がコードを実行できる環境はすべて影響範囲に入る。共用ホスティング、CIランナー、クラウドSaaSなどだ。
修正と緩和策
修正は2026年4月1日にメインラインカーネルへ取り込まれている（コミットa664bf3d603d）。algif_aead.cを2017年以前のout-of-place動作に戻す内容で、ページキャッシュページが書き込み可能なスキャッタリストに混入する経路そのものを断つ。Linux 7.0-rc7以降に適用済みで、6.18.22、6.19.12、7.0などのStable系列にも反映されている。
各ディストリビューションの対応状況は本日時点でこうなっている。Ubuntuは高優先度として追跡し、パッケージ単位で影響状況を公開している。Red HatはCVEページで深刻度を「Moderate」と評価し、ステータスは「Fix deferred(修正延期)」と表示されている。SUSEは独自評価で「moderate」、CVSSスコアは5.8と算出した。Debian Security Trackerでは、bullseye、bookworm、trixieが「vulnerable」、forkyとsidが「fixed」と表示されている。Amazon LinuxはAL2およびAL2023の両方で対応情報が掲載されている。
すぐにカーネルパッチが当てられない環境向けに、暫定的な緩和策が提示されている。
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null
algif_aead モジュールを無効化することで、AF_ALG経由でのAEAD操作の到達面そのものをふさぐ。多くの環境では algif_aead を実用的に使っていないため、副作用は限定的とされる。ただしIPsec関連のアプリケーションを動かしている場合は、影響評価が必要だ。
Tharros社の主任脆弱性アナリスト、ウィル・ドーマン(Will Dormann)は、Fedora 42およびそれ以降ではアップデートが提供されているものの、CVE-2026-31431に関する公式アドバイザリや公式の認知が出ていないと指摘している。
Theori研究者は、マルチテナントのLinuxホスト、Kubernetes/コンテナクラスタ、CIランナー/ビルドファーム、ユーザーコードを動かすクラウドSaaSの4つを、パッチ優先度の最上位として推奨している。
・ ・ ・
Copy Failが残した問いは、単一バグの深刻度では終わらない。9年間誰も気づかなかった論理の欠陥を、AIが約1時間で釣り上げた。同じ釣り竿は、まだ無数の交差点を待っているはずだ。
参照元
- Xint Code - Copy Fail: 732 Bytes to Root on Every Major Linux Distribution
- Linux kernel commit a664bf3d603d
他参照
