Copy Fail – CVE-2026-31431
(copy.fail)- 2017年以降、すべてのLinuxディストリビューションで root 権限を取得できるコンテナ脱出型の権限昇格脆弱性
- Linuxカーネルの暗号モジュール（
authencesn）に存在する単純なロジック欠陥を悪用し、複雑なタイミング調整（レースコンディション）やカーネルバージョンごとの調整なしに、732バイトの Python スクリプト1本で実行可能 - 中核となる原理は、Linuxがファイル実行時に参照するメモリ内キャッシュ（ページキャッシュ）を改変することにあり、
AF_ALG（カーネル暗号ソケット）とsplice()（データコピーシステムコール）を組み合わせて、setuid バイナリのキャッシュ上のコピーに4バイトを書き込む- 実際のディスク上のファイルは変更されないため、フォレンジック用ディスクイメージに痕跡が残らないステルス攻撃
- 再起動するかメモリが解放されるとキャッシュは元に戻るため、従来のファイル完全性チェックでは事後検知が難しい
- ページキャッシュはホスト全体で共有されるため、Kubernetes環境では1つの Pod がこの脆弱性を悪用することでホストノードを掌握し、他テナントのコンテナにまで侵入するコンテナ脱出が可能
- Ubuntu 24.04、Amazon Linux 2023、RHEL 10.1、SUSE 16で直接検証されており、非特権のローカルユーザーアカウントさえあれば、ネットワークアクセスやカーネルデバッグ機能なしで即座に動作
- 既存のLinux権限昇格（LPE）脆弱性は、試行ごとの成功率が30〜80%で特定のカーネル範囲でしか動作しないことが多いが、Copy Fail は単一試行で100%の成功率、9年間（2017〜2026）にわたり全ディストリビューションが対象
- 同じページキャッシュ改変系であるDirty Pipe（パイプバッファフラグの悪用）や Dirty Cow（タイミング競合が必要）と異なり、レースコンディションなし・ディストリビューションごとのオフセットなし・再コンパイル不要という点で、はるかに単純かつ強力
- 最も緊急性が高い対象: マルチテナントLinuxホスト、Kubernetes/コンテナクラスタ、CIランナー（GitHub Actions セルフホスティング、GitLab Runner など）、ユーザーコードを実行するクラウドSaaS — 信頼できないコードが共有カーネル上で実行されるすべての環境
- 最優先の対策はカーネルパッチ（メインラインコミット
a664bf3d603d）— 2017年に導入された暗号モジュールのインプレース最適化を巻き戻し、ページキャッシュページが暗号演算の書き込み対象に含まれないよう修正 - パッチ前の暫定対策として
algif_aeadモジュールを無効化でき、dm-crypt/LUKS・kTLS・IPsec・SSH など一般的な暗号化機能には影響しない - コンテナ・サンドボックス・CIランナーなど、信頼できないワークロード環境では、パッチ適用の有無にかかわらず、seccomp で
AF_ALGソケットの作成をブロックすることを推奨 - Xint の Taeyang Lee が「
splice()がページキャッシュページを暗号サブシステムに渡す構造は未開拓のバグクラスだ」という初期の洞察を導き、Xint Code がカーネルcrypto/サブシステムを約1時間で自動スキャンして発見したAI支援型脆弱性検出の事例
5件のコメント
Rocky Linux はまだパッチが出ていないようですね
RHEL
AlmaLinux
Rocky Linux
copy fail、cve-2026-31431などで検索Rocky Linux を使用中で再起動できないなら、https://github.com/wgnet/wg.copyfail.patch の
bpftoolによるブロックが有効です。https://kb.ciq.com/article/rocky-linux/rl-cve-2026-31431-mitigation
パッチは一応あるのですが……サブスクリプションサービスのリポジトリでのみ提供されています。CE バージョンはパッチ未提供です。（9.7、10.1で確認）
2026-05-05 にパッチが出ました。
2026-05-10 に新しいセキュリティオプションがあります。
https://forums.rockylinux.org/t/…
sudo dnf --enablerepo=security update
セキュリティリポジトリを追加すると、RHEL ソースの反映とは別にセキュリティ対策が可能なようです。
Ubuntu をお使いの方は、対処方法のガイドが出ているので参考になると思います。
https://discourse.ubuntu.com/t/…
Hacker News の意見
Linux カーネルの crypto コードを扱う立場からすると、定期的に出てくる AF_ALG エクスプロイト には本当にうんざりする
AF_ALG は十分なレビューなしにずいぶん前にカーネルへ入ったもので、構造があまりに複雑なうえ、非特権の userspace プログラムに巨大な攻撃面を開いてしまっている
しかもほとんど不要だ。userspace にはすでに独自の暗号化コードがあり、カーネルの crypto コードはもともと dm-crypt のようなカーネル内部の用途向けのものだ
今回のエクスプロイトにある authencesn も、実質的には IPsec の内部実装の詳細であり、これを汎用的な userspace 向け暗号化/復号 API として公開したのはそもそも誤りだと思う
Linux カーネル設定を管理しているなら、すべての CONFIG_CRYPTO_USER_API_* オプションを無効化することを強く勧める
それだけでも、今回のバグだけでなく過去や将来の AF_ALG バグのかなりの部分は悪用不可能になっていたはずだ
もし userspace プログラムが壊れるなら、userspace の crypto コードへ移行するのを支援するのが正しく、実際すでにそう変わったものもある
そもそも AF_ALG は、エクスプロイト以外にはあまり使い道がなかった
以前ならこうした userspace API もそれなりに許容されたかもしれないが、syzbot や LLM 支援のバグ検出がある今では、もう持ちこたえるのは難しい
カーネルモードでしかアクセスできない ハードウェアアクセラレータ を userspace から使えるようにすること、鍵をアプリケーションメモリ内に長く残さずカーネルへ渡せること、組み込みのようにメモリが厳しい環境で userspace の crypto ライブラリよりフットプリントを減らせることが根拠として挙げられている
これが十分に妥当な正当化かは判断できないが、少なくとも理由自体はある
Linus はカーネルに何を入れるかかなり厳しいことで知られているので、こういう API が入った経緯は興味深い話になりそうだ
ハッシュと暗号化を一般的な
read(2)/write(2)呼び出しで扱えるようにする公開プロセスで何か 混乱 があったようだ
ベンダー各社がこの脆弱性を深刻に扱っておらず、そのため複数のディストリビューションでまだ未パッチのまま残っている
https://access.redhat.com/security/cve/cve-2026-31431 には "Moderate severity", "Fix deferred" とあり、Debian、Ubuntu、SUSE の追跡ページも似たような見え方だった
しかし upstream はこれを 脆弱性 として明確にコミュニケーションしておらず、Linus と Greg はカーネルでそうした分類自体を概念的にあまり重視しない傾向がある
それでもローカルで root 権限昇格が可能なのだから、通常は高優先度と見るのが妥当に思える
https://ubuntu.com/security/cves/about#priority
どの カーネルバージョン が脆弱で、どのバージョンで修正されたのかが本文にすぐ書かれていないのは残念だ
とくにこれは builtin モジュールなので
rmmodで簡単に外せないだけに、なおさらそう思うFedora 44 の kernel 6.19.14 が脆弱か確認しようとして、linux-cve-announce メーリングリストの投稿 https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u を見つけた
そこには 6.18.22、6.19.12、7.0 でそれぞれ該当コミットによって修正されたと書かれていて、参考になった
推奨された緩和策どおりにカーネルモジュール
algif_aeadを modprobe 設定でブロックしたか確認したいなら、難読化されたシェルコードを丸ごと実行する必要はない以下のように Python を数行使うだけで、モジュールが実際にロードされるかを読みやすく確認できる
python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'緩和策が正しく適用されていれば、
modprobe algif_aeadもエラーで失敗するはずだ影響を受ける OS 上で 完全自律型 AI エージェント を一般ユーザー権限で動かしている人なんて、まさかいないよね
ゼロデイのプロンプトインジェクション と組み合わされると、かなり悲惨なことになり得る
curl | shでインストールするのを業界標準みたいにはしなかったよねLPE は local privilege escalation の意味だ
セキュリティ界隈の略語は多すぎて、文脈から推測はできたけれど、やはり最初は展開して書いてほしい
ただ、より幅広い読者に向けた文章なら明示的に定義しておく方がよいという点には同意する
しかもこの記事全体が AI 生成物 のようにも見える
これはちょっと笑える
ページには RHEL 14.3 で動くと書いてあるが、そんなバージョンは存在しない
現在の RHEL は 10.x なので、まるで TARDIS にでも乗ったのかと思った
gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2)のように表示されることがあり、下の例にも似た痕跡が見えるhttps://github.com/anthropics/claude-code/issues/40741
https://docs.oracle.com/en/database/oracle/tuxedo/22/otxig/software-requirements-red-hat-enterprise-linux-10-64-bit.html
6.12.0-124.45.1.el10_1とも書かれていて、それは明らかに RHEL 10 カーネルだこの手の誤字はむしろ人間がよくやる
コピペした長い数字は正確なのに、簡単な数字は手入力で打ち間違えるようなものだ
問題を説明するために情報を急いで集める過程があり、そう、マーケティング的な性格もあった
そのため細かなミスが少し入ってしまっていて、指摘に感謝している
https://access.redhat.com/articles/red-hat-enterprise-linux-release-dates
ページの一番下にある "Talk to our security experts" まで見たら、そのセキュリティ専門家の名前はもしかして Claude なのでは、という気分にさえなった
RHEL 9/10 では algif_aead がモジュールではなく builtin なので unload できなかった
そのため次善策として systemd 経由で AF_ALG をブロックする方法 を見つけ、露出している各サービスごとに drop-in が必要になる
主要な
sshdとuser@を扱う Ansible プレイブックもあるhttps://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da
initcall_blacklist=algif_aead_initをカーネルのブートオプションに追加して再起動する方法も使えたそうするとエクスプロイトはもう動作しなかった
cronjobやslurmjobのような別の実行経路がどうなるのか気になるし、個別サービスごとに設定する代わりに、systemd レベルで全プロセスが継承するようにできる方法があればよいのだがこのエクスプロイトは SUID バイナリ を差し替えて PID 0 として実行させる方式のようだ
だがサイトは Kubernetes / container clusters や CI runners & build farms からの脱出まで可能だと主張している一方で、実際にコンテナ、特に user namespace 脱出 を裏づける説明は見当たらない
rootless Podman で試したところ、予想どおりコンテナから抜け出せなかった
また「2017 年以降にリリースされたすべての Linux ディストリビューションを root にする」とも主張していたが、実際にテストされたのは 4 つだけで、Alpine では動かなかった
"Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."と予告しているhttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee3
ただし実際に悪用可能かどうかは、最新のメジャーリリースなのか、古いブランチのメンテナンスカーネルなのかによって変わるだろう
それでも PoC を 24.04 インスタンスで実際に動かしてみると、脆弱性自体は本物らしく、十分に大きな問題に見える
ただし影響を受けるディストリビューションの数は主張よりずっと少なそうで、2017 年以降のすべてのディストリビューション という表現とはかなり隔たりがある
たとえば Ubuntu は、私の解釈が正しければ 16.04 EOL にも多少影響があり、実際の主な影響は最近配布され始めた vendor カーネルである
linux-gcp、linux-oracle-6.7といった 6.17 系 にあるように見えるただし追加の手順は必要で、Alpine も根本的な脆弱性自体はあって、単にスクリプト調整が必要なだけかもしれない
結局のところ、これは完成された汎用エクスプロイトではなく PoC だ
ページ自体はかなり vibecoded っぽく広告臭もあるが、脆弱性は本物で、危険度も高そうだ
今日大きなセキュリティアップデートが来た理由が分かったので、更新の優先度を上げるべきだろう
実際にバグを見つけてパッチするという形で OSS エコシステムに意味のある貢献 をしつつ、同時に自分たちのセキュリティツールを売っている構図だからだ
ただ、今どき誰が Web ページを手作業でいちいち作るのかとも思うし、とくに カーネル開発者 ならなおさらそうだろう