Linux全ディストロを揺るがす Copy Fail (CVE-2026-31431) — 暗号化サブシステムからroot奪取まで

はじめに

2026-04-30、Linuxカーネルに2017年から潜んでいた重大な権限昇格脆弱性「Copy Fail」(CVE-2026-31431) が公開された。Hacker Newsとはてブで同時多発的にトップ入りし、Reddit r/programmingやopenwall oss-securityでも議論が止まらない。

本脆弱性が恐ろしいのは、732バイトのPythonスクリプト一発でローカル権限昇格が確実に成立し、しかもページキャッシュしか汚染しないためファイルハッシュでは一切検知できない点にある。本記事ではAF_ALGとsplice()の相互作用という根本原因を噛み砕き、なぜ8年も気付かれなかったのか、サーバ運用者・コンテナ基盤運用者が今すぐ何をすべきかを整理する。

何が起きたのか — 影響範囲とディスクロージャーの混乱

発見者はXint Code。AI支援ツールで「暗号化サブシステムとページキャッシュの相互作用」という観点で監査をかけたところ、わずか1時間ほどで脆弱性に到達したと報告している。AI時代のカーネル監査がいよいよ実戦投入されつつあることを示す事例でもある。

影響範囲は文字通り「2017年以降のほぼ全てのLinux」。原因は2017年にコミット 72548b09 (kernel 4.14系) で導入されたAEAD系処理にあり、Ubuntu / RHEL / Amazon Linux / SUSE を含むメジャーディストロ全てが対象となる。修正は上流で2026-04-11にkernel 6.19.12 / 6.18.22として配信されたが、openwallのスレッドではSam Jamesが6.12 / 6.6 / 6.1 / 5.15 / 5.10 の長期サポートカーネルが未パッチ状態のまま開示されたと指摘している。

さらに開示プロセス自体に問題があった。Eddie Chapmanが「embargo broken early」と懸念を呈しており、報告者がlinux-distros MLに通知しなかったため各ディストリビューションへ事前共有が回らなかった。これは「公開と同時に攻撃が成立し、かつディストロのパッケージは未追従」という最悪のタイミング差を生む。すなわち本記事を読んでいる時点でも、利用中のディストロ提供カーネルでは未対応の可能性が十分にある、ということだ。

技術詳細：AF_ALG × splice() × authencesn による4バイト書き込み

Copy Failの本質は、Linuxカーネルの暗号化サブシステム (AF_ALG) と**splice()システムコール**の相互作用に潜む4バイトの過剰書き込みである。

splice()は本来、カーネル空間内でページ間のデータ移動をゼロコピーで行うための仕組みで、ページキャッシュ上のデータを別のファイルディスクリプタへ流し込める。一方AF_ALGはユーザ空間からカーネルの暗号化APIを呼び出すソケットインタフェースで、AEAD（認証付き暗号化）系のalgif_aeadモジュールを通じて処理を実行する。

問題は、AEADのin-place処理がsplice()経由で渡されたページキャッシュを「書き込み可能なバッファ」として扱ってしまった点にある。具体的には：

攻撃者はsplice()で読み取り専用にmmapした setuid バイナリのページキャッシュをAF_ALGソケットへ流し込む。
AEADテンプレートの一つauthencesnが処理途中でバッファ末尾の4バイトを意図せず上書きする。
setuidバイナリのテキスト領域が書き換わり、suやnewgrpを実行した瞬間にroot権限の任意コード実行が成立する。

実証記事 (Zennの harupu 氏) によれば、EC2 Ubuntu 22.04上でPoCを実行すると -rwsr-xr-x のSetUIDバイナリ群が片端から侵害可能で、攻撃は一瞬で確実に成功する。レースコンディション系の脆弱性と違い「100回試して数回成功」ではなく「実行すれば必ず通る」性質を持つ。

修正パッチ (torvalds/linux@a664bf3d) は単純で、AEADのAEAD処理をin-place方式からout-of-place方式に戻すだけ。8年間この単純な変更が放置されていたのは、「splice()経由でページキャッシュが書き込み可能扱いになる」という発生条件が監査の死角に入り続けていたためだろう。

エンジニアへの影響：検知不可能性とコンテナ脱出

Copy Failが既存の権限昇格脆弱性と決定的に違うのは、ステルス性とマルチテナント環境への波及にある。

1. ファイルハッシュ検知をすり抜ける。 攻撃はページキャッシュに対してのみ行われ、ディスク上のファイル自体は1バイトも変更されない。AIDE / Tripwire / Wazuh などホストベースIDSが行うハッシュ整合性チェックは原理的に通り抜ける。Zennの実証記事でも auth.log にすら痕跡が残らないと報告されている — su 等のログ出力コードそのものが書き換えられて沈黙するためだ。再起動またはページキャッシュクリアで「証拠ごと消える」ため、フォレンジックの難度も高い。

2. コンテナ脱出の現実的なリスク。 ページキャッシュはホストOSとコンテナで共有される。共有ホスト上で動くコンテナの一つからalgif_aeadへアクセスできれば、ホスト上のsetuidバイナリのページキャッシュを汚染してホスト権限を取れる可能性がある。Kubernetesマルチテナント基盤やCIランナー、共用GPUサーバを運用している組織では、テナント分離前提が崩れる重大インシデントになり得る。

3. 即時ミティゲーション。ディストロのカーネルアップデートを待たずに今日打てる手段は二段構えで考える。

# 暫定対策：algif_aead モジュールの状態確認
lsmod | grep algif_aead

# ロード済みなら即時アンロード
sudo rmmod algif_aead

# 永続無効化（再起動後も有効）
echo "blacklist algif_aead" | sudo tee /etc/modprobe.d/disable-algif-aead.conf

algif_aead はユーザ空間からのAEAD暗号化APIで、IPSec設定ツールの一部や特定のVPN実装が利用するが、一般的なWebサーバ・APIサーバには不要なケースが多い。本番環境で無効化する前にIPSec / strongSwan / 一部の暗号化ライブラリへの影響を必ず確認すること。

4. 検知策。ホストベースの完全な検知は難しいが、ページキャッシュとディスクファイルのハッシュを定期的に比較する仕組みを入れれば、攻撃発生時点では検知可能だ。crashユーティリティや /proc/<pid>/maps 経由でメモリ上のテキスト領域をダンプし、/usr/bin/su などsetuidバイナリのオンディスク版とハッシュ比較するスクリプトを cron で回すのが現実的な対症療法となる。

まとめ

Copy Fail (CVE-2026-31431) は、AF_ALGのauthencesnテンプレートとsplice()の相互作用で、setuidバイナリのページキャッシュを4バイト書き換えて即座にrootへ昇格できるカーネル脆弱性。
影響範囲は2017年以降の全主要Linuxディストロ。修正はkernel 6.19.12 / 6.18.22で4月11日にリリース済みだが、LTSカーネル (6.12 / 6.6 / 6.1 / 5.15 / 5.10) は未パッチのまま開示された。
ページキャッシュ汚染ゆえにディスク上のファイルが変化せず、従来のハッシュベース検知をすり抜ける。コンテナ脱出の懸念もある。
暫定対策として algif_aead モジュールの無効化が有効。本対応はディストロからの更新カーネル適用を待つ。

「ローカル権限昇格はそんなに怖くない」という時代の通念は、マルチテナントなコンテナ基盤においては既に成立しない。Copy Failはその構造変化を改めて突きつける一件だ。今夜、運用しているLinuxホストのlsmod | grep algif_aeadを確認するところから始めたい。

今日のその他のニュース

Zigプロジェクトの「AI生成コード禁止」ポリシー (Hacker News 594pts): Simon WillisonがOSSコミュニティでのAI生成コントリビューション受け入れ問題を整理。Zigは品質と責任所在の観点から明確な拒否姿勢を表明し、議論を呼んでいる。
IBM Granite 4.1 (Hacker News 237pts): 8Bパラメータで32B MoE級の性能を主張するオープンモデル。エッジ推論やセルフホスト用途のLLM選定で要チェック。
Firebase AI Logic / Cloud Next 2026: Vertex AI in Firebase が Firebase AI Logic に進化、Phone Number Verification がGA、Cloud FunctionsとAdmin SDKがDart実験対応。Flutter × Firebaseのフルスタック開発体験が前進。