Linux カーネル「Copy Fail」(CVE-2026-31431)まとめ — 2017年以降ほぼ全ディストリが対象の権限昇格脆弱性と現実的な対策
2026年4月末に公開された Linux カーネルの権限昇格脆弱性「Copy Fail」(CVE-2026-31431、CVSS 7.8)の概要と対策をまとめます。algif_aead モジュールの2017年導入の in-place 最適化が原因で、低権限のローカルユーザーがページキャッシュ経由で root を取得可能。修正は in-place を out-of-place へ revert する形で 6.18.22 / 6.19.12 / 7.0 に投入されました。本記事では影響範囲・既知のディストリ対応・即時にできる緩和策(モジュール無効化、seccomp による AF_ALG 遮断)を実務目線で整理します。
Copy Fail(CVE-2026-31431)とは何か
Copy Fail(CVE-2026-31431、CVSS 7.8)は、2026年4月末に公開された Linux カーネルのローカル権限昇格(LPE)脆弱性です。Linux カーネル AF_ALG(ユーザー空間暗号 API)の AEAD ソケットインターフェースを担当する algif_aead モジュール の論理バグで、低権限のローカルユーザーが任意の読み取り可能ファイルのページキャッシュに対して、決定論的に4バイトの書き込みを行えるようになる、というものです。報道によれば 732 バイト程度の Python スクリプトで、setuid バイナリを書き換えて root を取得できると示されており、攻撃の信頼性は確率的ではなくほぼ確定で動くという性質を持ちます。
なぜ「Copy Fail」というニックネームか
本問題の原因は、AEAD(認証付き暗号)処理を「in-place」で行うように変更された2017年のコミット(mainline 4.14系で取り込まれた `72548b093ee3` 系の変更)に起因します。in-place 化により入力と出力のスキャッタリストが同じ位置を指すようになり、結果として「本来は読み取り元であるページキャッシュ上のページ」が、暗号レイヤーから見ると書き込み可能な出力先として扱われてしまう状態になっていました。つまり「コピーをサボる(in-place にする)最適化」が安全境界を破った形になり、これがニックネーム「Copy Fail」の由来とされています。
攻撃の流れ(概念)
影響範囲 — 2017年以降ほぼ全ディストリが射程
原因となったコミットは2017年のカーネル 4.14 系から入っているため、それ以降に出荷された Linux ディストリビューションのほぼ全てが影響対象です。公開資料で具体的に名前が挙がっているもの: - Ubuntu 24.04 LTS 系 - Amazon Linux 2023 系 - Red Hat Enterprise Linux 14.3 系 - SUSE 16 系 上記以外でも、algif_aead が有効になっている標準カーネルを使っている主要ディストリは原則として影響対象と考えるのが現実的です。
なぜ深刻か
通常のカーネル LPE 脆弱性に比べて、本件は次の特性で運用面のリスクが特に高いとされています: - race window がない: 競合実行を待つ必要がなく、確実に成功する単純なロジック欠陥 - オフセットの推測が不要: アドレス漏洩や ASLR の推定が不要 - クロスディストリで同じスクリプトが通る: 1つのエクスプロイトで複数の OS を制圧 - コンテナ内・共有ホスト内で意味を持つ: マルチテナントな Linux ホスト、CI ランナー、共有踏み台などで深刻 - 改ざん対象が「読み取り専用ファイル」のページキャッシュ: setuid バイナリのバイトを直接書き換えて実行で root へ
公式の修正方針 — in-place を out-of-place へ revert
上流の修正パッチは、2017年に入った in-place 最適化を revert する形で、AEAD 処理を out-of-place(入出力スキャッタリストを別々に確保)に戻す方針で投入されています。「ページキャッシュのページが書き込み可能な出力先として暗号レイヤーから見えてしまう」という根本構造を断つアプローチです。修正が含まれるバージョンとして公開資料で挙がっているのは 6.18.22 / 6.19.12 / 7.0 系です。各ディストリは本家の修正をバックポートする形で順次配信しています。
対策 — 推奨される優先順位
現場でやるべきことを優先度順に整理します。 1. ベンダ提供のカーネル更新を適用して再起動(最優先): Ubuntu / RHEL / Amazon Linux / SUSE 等の各ベンダが配信するパッチ済みカーネル(または LTS バックポート)を当て、再起動してパッチ済みカーネルで起動していることを `uname -r` で確認 2. 即時に再起動できないホストでは algif_aead モジュールを止める: 後述のモジュール無効化を適用し、攻撃面を消す 3. より広い遮断: アプリ側で AF_ALG ソケット自体を seccomp で塞ぐ(`socket()` の domain `AF_ALG` を拒否)、またはコンテナランタイムのプロファイル更新 4. 検知・監査: `algif_aead` の load イベント、AF_ALG 関連の異常な system call パターン、setuid バイナリの完全性監査(AIDE / OSSEC / 自前ハッシュ照合)を強化
緩和策コマンド例(再起動できないとき)
algif_aead モジュールの無効化(永続化)
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead 2>/dev/null || trueこれで `algif_aead` の今後のロードを禁止し、現在ロードされていれば落とすことを試みます(使用中の場合は `rmmod` がエラーになるため、依存関係を確認して順次落とすか、再起動を検討)。 確認
lsmod | grep algif_aead
cat /etc/modprobe.d/disable-algif.conf影響評価: AF_ALG / algif_aead を使うアプリは限定的(特定の暗号ライブラリ・特殊な dm-crypt 設定等)です。多くのサーバ・コンテナワークロードでは無効化しても影響は出にくい一方、暗号系ミドルウェアを使っている場合は事前に確認してください。
コンテナ・クラウドでの考慮事項
コンテナ環境ではホスト側カーネルが共有されるため、コンテナ内に低権限ユーザーがいる時点でホスト乗っ取りに繋がりかねない点が重要です: - マネージド K8s(EKS / GKE / AKS): ノードイメージのカーネル更新がベンダから配信される。ノードプールのローテーションを早めにスケジュール - 自前 K8s / Nomad: ノードのカーネル更新+再起動を計画的に進行(ローリング) - マルチテナント PaaS / 共有 CI: パッチ適用までの間、コンテナの seccomp プロファイルで `socket(AF_ALG, ...)` を拒否する設定を緊急で配布 - AWS / GCP / Azure: 各社のセキュリティ告知、Inspector / Defender for Cloud 等の検知ルールを確認
オブライトでの対応方針
オブライトでは、自社運用および受託先のサーバ群を対象に次の手順で対応を進めています: 1. ベンダ告知をモニタリングし、提供され次第パッチ適用→再起動 2. 再起動が業務影響的に難しいシステムについては、`algif_aead` モジュール無効化を一次対応として適用 3. setuid バイナリの完全性ハッシュを取り直し、改ざん検知を強化 4. 共有ホスト・CI ランナー・ジャンプサーバなど、低権限ユーザーが常駐する系を優先的にパッチ ネットワークシステム や ソフトウェア開発 でインフラ運用を含む受託をご相談いただいているお客様向けには、個別に影響評価とパッチ適用計画をご提供できます。気になる方は お問い合わせ からどうぞ。
FAQ
Q1: クライアント PC(個人用 Linux デスクトップ)でも対応必要ですか? A: 必要です。ローカル権限昇格は、別の経路(ブラウザ脆弱性、悪意あるパッケージ、SSH 経由の侵入など)で低権限を取った攻撃者が「最後の一押し」で root 化する典型的なステップです。デスクトップでも例外なくカーネル更新を当ててください。 Q2: AF_ALG を使っているアプリってありますか? A: 限定的です。dm-crypt の特定構成、特殊な暗号ライブラリ、kTLS の一部経路などで利用例があります。一般的な Web / DB / アプリサーバでは使っていないことが大半なので、`algif_aead` 無効化の副作用は出にくい構成が多いです。 Q3: コンテナイメージ内のカーネルだけ古いと危ないですか? A: 危ないのはホストカーネルです。コンテナはカーネルを共有するため、コンテナイメージ内のユーザースペースは関係なく、ホストの kernel パッチ適用がすべての出発点になります。 Q4: 暫定で algif_aead を無効にした後、いつ戻せばいい? A: パッチ済みカーネルで再起動済みであることを `uname -r` と各ディストリの kernel changelog で確認できたタイミングで、必要なアプリが再度 algif_aead を要求するなら戻せます。多くの環境では戻さなくても運用に支障は出ません。 Q5: 検知できる兆候はありますか? A: AF_ALG ソケットの異常な作成パターン、setuid バイナリのハッシュ変化、auditd で `socket(AF_ALG, ...)` を監査する、などが現実的な検知ポイントです。
参考文献
- oss-security: CVE-2026-31431: CopyFail(openwall.com、初出告知、2026/4/29) - Copy Fail: 732 Bytes to Root on Every Major Linux Distribution(Xint) - Nine-year-old Linux kernel flaw enables reliable local privilege escalation(Help Net Security) - New Linux 'Copy Fail' Vulnerability Enables Root Access on Major Distributions(The Hacker News) - What we know about Copy Fail(Bugcrowd) - CVE-2026-31431: "Copy Fail" Linux kernel flaw(Sysdig) - CERT-EU 2026-005 高深刻度 Linux カーネル脆弱性 - Debian セキュリティトラッカー: CVE-2026-31431
お気軽にご相談ください
お問い合わせ