CVE-2026-31431「Copy Fail」とは？影響範囲と今すぐ行うべきパッチ・緩和策をわかりやすく解説

Copy Fail（CVE-2026-31431）は、2026年4月29日に公開されたLinuxカーネルのローカル権限昇格（LPE）脆弱性です。深刻度はCVSS 3.1で7.8（HIGH。ベンダーにより評価に幅があります）。2017年以降にビルドされたほぼすべての主要ディストリビューションが対象で、一般ユーザーが確実にroot権限を奪取できてしまう点が問題視されています。すでに悪用が確認され、CISAの「悪用が確認された脆弱性カタログ（KEV）」にも追加されました。本記事では、攻撃の細部ではなく「自社環境が対象か」「どう直すか」「どう守るか」という防御の実務に絞って解説します。

まとめ（先に結論）

急いで判断したい方向けに要点を先に整理します。

• 何が問題か：カーネルの暗号インターフェース（AF_ALG）の論理欠陥を突かれると、読み取り可能なファイルのページキャッシュに任意の4バイトを書き込まれ、/usr/bin/suのようなsetuidバイナリのメモリ上のコピーを書き換えてroot権限を奪われます。
• どれくらい深刻か：レース条件が不要で決定論的に成功し、コンテナの隔離を越える（コンテナ脱出の足がかりになる）うえ、ディスク上のファイルが変わらないため従来のファイル改ざん検知では捉えにくい——という三拍子がそろっています。
• 対象範囲：2017年以降のLinuxカーネル（4.14以降。6.18系は6.18.22未満、6.19系は6.19.12未満が該当）。修正版は6.18.22 / 6.19.12 / 7.0。Ubuntu 26.04（Resolute）以降は影響を受けません。
• 今すぐやること：①カーネルを修正版へ更新（恒久対策・要再起動）。②すぐ更新できないなら緩和策（ただし後述のとおりmodprobe＋rmmodは環境によっては効きません）。③CI/CDランナー・マルチテナント基盤・踏み台サーバーを最優先で対処。

以下、それぞれを順に掘り下げます。

CVE-2026-31431「Copy Fail」とは何か

Copy Failは、セキュリティ企業Theoriが2026年4月29日に公開したLinuxカーネルの脆弱性です。同社のAI支援セキュリティ解析（Xint）を用い、研究者Taeyang Lee氏が短時間で発見したと報告されています。通称の「Copy Fail」は、暗号処理のコピー（入出力）が本来書き込んではいけない領域にまで到達してしまう挙動に由来します。

分類はローカル権限昇格（LPE）です。インターネット越しに単体で悪用できるタイプではなく、すでにサーバー上でコードを実行できる状態の攻撃者が、より強い権限（root）へ昇格するために使われます。Web経由の侵入、SSHの足がかり、CIランナーへの悪意あるプルリクエストなど、初期侵入の手段と組み合わさったときに本領を発揮するため、「侵入された後の被害を最大化する脆弱性」と捉えると実務的です。公開時点で約732バイトという極小のPython実証コード（PoC）が出回ったことも、攻撃の敷居の低さを示しています。

Dirty Cow・Dirty Pipeとの違い：レース不要で「確実に効く」

過去の著名なLinux権限昇格脆弱性であるDirty CowやDirty Pipeと比較されますが、決定的な違いはレース条件（競合状態）を必要としない点にあります。何度も試行したりタイミングを狙ったりせずに一発で成立するため、再現性と信頼性が桁違いに高く、同じ手口が多数のディストリビューションでそのまま通用します。

なぜ起きるのか：仕組みをかんたんに

原因は単一のバグではなく、長年積み重なった独立した変更が交差した結果です。順を追うと理解しやすくなります。

まずAF_ALGは、ユーザー空間のプログラムがカーネル内部の暗号処理を呼び出すためのソケットインターフェースで、非特権ユーザーでも利用できます。次にsplice()というゼロコピーI/Oの仕組みを使うと、ファイルのページキャッシュ（ファイル内容をメモリ上に保持する共有キャッシュ）のページを、そのままカーネルの暗号処理へ渡せます。そして2017年に入ったin-place最適化（処理の入力バッファと出力バッファを同一メモリで共用してコピーを省く高速化）によって、splice経由で渡されたページキャッシュのページが、書き込み先のバッファとして再利用される経路が生まれました。

最後の引き金が、IPsecの拡張シーケンス番号に対応した暗号テンプレートauthencesnの挙動です。GCMやCCM、通常のauthencといった一般的なAEADは出力範囲の外に書き込みませんが、authencesnだけは内部処理の都合で出力境界の外側に4バイトを書き込みます。これらが連鎖すると、その4バイトがページキャッシュ上のファイル内容に直接届いてしまうのです。攻撃者は読み取り可能なファイル（典型的には/usr/bin/suなどのsetuidバイナリ）のメモリ上のコピーを書き換え、そのバイナリが実行された瞬間にroot権限を得ます。書き込み先はメモリ上のキャッシュであってディスク上のファイルではないため、再起動すれば改ざんは消える一方、稼働中は即座に有効になります。

修正パッチは、この2017年のin-place最適化を撤回し、入力と出力を別バッファに分離する（out-of-place動作へ戻す）方針で対応しています。これによりページキャッシュのページが書き込み先に混入する経路自体が塞がれます。

影響範囲：対象カーネルと主要ディストリビューション

影響を受けるのは2017年以降のLinuxカーネル（4.14以降）で、各系列では6.18.22未満の6.18系・6.19.12未満の6.19系が該当します。逆に、修正が取り込まれた6.18.22・6.19.12・7.0以降、およびUbuntu 26.04（Resolute）以降は影響を受けません。Theoriが実機で攻撃成立を確認した主要ディストリビューションは次のとおりです。

これら以外でも、2017年以降のカーネルを使うDebian・Fedora・Arch・Rocky Linux・AlmaLinux・Oracle Linuxなどは原則として対象です。判定の基本は「kernel 4.14以降か」「ベンダーが個別にバックポート修正を出していて適用済みか」の2点で、最終的には各ベンダーのセキュリティ情報を一次ソースとして確認します。

自社環境が対象か確認する方法

まずホスト側で稼働カーネルを確認し、修正版と突き合わせます（コンテナ内ではなくホストOSのカーネルが判定基準です。コンテナはホストのカーネルを共有するため、コンテナを最新にしてもホストが脆弱なら攻撃は成立します）。

uname -r
# 表示されたバージョンを、ベンダーのアドバイザリやパッチ済み版と照合する
# Ubuntu/Debian系では changelog にCVE記載があるかも確認できる
apt changelog linux-image-$(uname -r) | grep -i -E "CVE-2026-31431|algif_aead"

新しいカーネルをインストールしただけでは反映されず、再起動して初めて切り替わります。また「新カーネルが入った」ことと「Copy Failパッチが含まれる」ことは必ずしも一致しないため、changelogで明示的な対応を確認してから再起動するのが安全です。確認の一次手段は公式トラッカーでのバージョン照合です。補助として、システムファイルに触れず一時ファイルだけで脆弱性の有無を判定する非破壊の検査スクリプトもコミュニティから公開されています。ただし配布元のリポジトリには攻撃コード本体が同梱されている場合があるため、スクリプトの内容を必ず確認し、自身が管理・許可された環境でのみ実行してください。

対策①：カーネルパッチの適用（恒久対策）

根本的な対策は修正版カーネルへの更新です。各ベンダーのアドバイザリでCVE-2026-31431が明記された対象パッケージを適用します。

更新コマンドの例は次のとおりです（対象パッケージ名はディストリにより異なるため、上表のアドバイザリで確認してください）。

# Ubuntu / Debian系
apt update && apt upgrade linux-image-generic   # Ubuntu
apt update && apt upgrade linux-image-amd64     # Debian
 
# RHEL / Rocky / AlmaLinux / Amazon Linux 2023系
dnf update kernel kernel-core
 
# SUSE
zypper patch

カーネル更新には再起動が伴います。再起動枠がすぐに取れない本番環境では、Canonical Livepatch・Red Hat kpatch・SUSE kGraftといった無停止のライブパッチが有効な選択肢です。ただしライブパッチは次回再起動までの暫定的な位置づけのため、計画停止時には正規パッケージでの恒久適用を済ませておきます。マネージドサービス（EKS・GKE・AKSなどのノード、Lambda・Cloud Run等のサーバーレス）は、責任共有モデル上ホストのパッチがプロバイダー側で適用されるケースが大半です。一方でEC2・Compute Engine・Azure VMなど自前管理のVMは利用者側でカーネル更新を行う責任範囲となるため、対応漏れがないか確認しましょう。

対策②：すぐに更新できない場合の暫定緩和策（重要な注意あり）

公開当初、多くの情報源が「algif_aeadモジュールを無効化すれば再起動なしで即時に防げる」として、次のような手順を推奨しました。

# 公開当初に広まった手順（環境によっては効きません・下記注意を参照）
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead

ここに重大な落とし穴があります。多くのディストリビューションではalgif_aeadがカーネルに組み込み（CONFIG_CRYPTO_USER_API_AEAD=y）になっており、その場合modprobe.dの設定でロードを止めることもrmmodで取り外すこともできません。コマンドはエラーを出さずに通るのに、システムは無防備のまま——という誤った安心感を生みます。まず組み込みかどうかを確認してください。

# 出力が "y" なら組み込み（modprobe/rmmodは無効）／"m" ならモジュール
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

組み込み（=y）の環境では、次のいずれかの代替策を用います。

• カーネルパラメータでinitcallを無効化：grubby等でinitcall_blacklist=algif_aead_initを付与し再起動する。再起動後にカーネルのコマンドラインへ反映されていることを確認します（こちらは再起動が必要です）。
• コンテナはseccompでAF_ALGを遮断：信頼できないコードを動かすコンテナ・CIランナー・Kubernetesでは、socket()の第1引数がAF_ALG（値38）の呼び出しをseccompプロファイルで拒否します。AF_ALGをコンテナ内で必要とするケースは稀なため、業務影響はほぼ生じません。KubernetesではPodのsecurityContext.seccompProfileで適用できます。
• eBPF-LSMでソケット生成を拒否：モジュールを残したまま、正規利用者以外のAF_ALGソケットのbindをLSMフックで拒否する方法もあります。

無効化・遮断による業務影響も整理しておきます。一般的な暗号処理の大半はAF_ALGを経由しないため、影響は限定的です。

影響を受けるのは、AF_ALG経由でAEAD暗号を呼び出す一部のアプリ（afalgエンジンを有効化したOpenSSLや、ハードウェア暗号オフロードを使う構成など）に限られます。心配な場合は、無効化前にauditdで30分〜1時間ほどAF_ALGの利用プロセスがいないかを確認すると安全です。いずれにせよ緩和策は時間稼ぎであり、計画停止枠を確保して恒久パッチへ移行するのが原則です。

検知：従来のファイル改ざん検知が効かない理由と監視設計

Copy Failの厄介さは、改ざんがメモリ上のページキャッシュに対して行われ、ディスク上のファイルが変わらない点にあります。このため、AIDEやTripwireのようなチェックサム比較型のファイル整合性監視（FIM）は、再起動やキャッシュ破棄の後に正規バイナリが読み直されると「正常」と判定してしまいます。inotify/fanotifyやauditdの-w監視も、通常のファイル書き込み（VFS層）をフックする設計のため、カーネル内部経由の書き込みではイベントが発火しません。

そこで検知の発想を、改ざん結果ではなく攻撃の前段階の挙動に移します。具体的には、通常運用ではほとんど発生しないAF_ALGソケットの作成を監視します。

# auditd で AF_ALG ソケット作成を記録（64bit環境の例）
-a always,exit -F arch=b64 -S socket -F a0=38 -k AF_ALG_SOCKET
# ※32bit(i386 ABI)のプロセスも監視する場合は socketcall 経由になるため、別途 arch=b32 のルールを追加する

このルールでログが出た場合は調査対象として優先度を上げます。より低オーバーヘッドで高粒度に捉えたい場合は、Falco・Tetragon・TraceeといったeBPFベースの監視ツールが有効で、コンテナやKubernetes環境にも導入しやすいのが利点です。auditdは長期運用実績とコンプライアンス対応に強みがあるため、両者を補完的に併用する多層検知が現実的です。なお、被害の疑いがある場合は再起動するとメモリ上の証跡が消えるため、調査時は再起動前のメモリ保全（LiME等）を検討してください。

優先的に対処すべき環境

限られた工数で対応する場合、リスクの構造が高い環境から着手します。最優先は信頼できないコードを同一カーネルで実行する環境です。

• CI/CDランナー：特にセルフホスト型や共有ランナー。悪意あるプルリクエスト等で攻撃コードが紛れ込みやすく、ホストが使い回されると改ざんの影響が後続ジョブに及びます。使い捨て化（ジョブごとに新規VM/Pod）も有効です。
• マルチテナント基盤・共有ホスト：SaaS、共有ホスティング、研究室の共有計算機など。ページキャッシュがホストで共有されるため、1テナントの侵害が他テナントへ波及します。
• 踏み台（ジャンプ）サーバー：多数の本番系への経路となり、鍵やトークンが集まるため侵害時の影響範囲が広く、原則として最優先で扱います。
• Kubernetesノード：単一Podの侵害から同一ノードのkubelet等の特権プロセスへ波及し得ます。ノードプール単位で更新状況を確認し、未対応ならパッチ済みイメージへローテーションします。

逆に、信頼できる利用者のみが触れる単一ユーザーのワークステーションなどは相対的に優先度を下げ、定期メンテのサイクルに乗せる判断も現実的です。

よくある質問（FAQ）

リモートから直接攻撃される脆弱性ですか？

いいえ。単体ではリモート悪用できず、すでにサーバー上でコードを実行できる状態が前提です。ただしWeb経由の侵入やSSHの足がかりと組み合わさると、最終的にrootを奪われる踏み台になります。

パッチを当てたのに検査で「脆弱」と出ます。

カーネル更新は再起動して初めて反映されます。再起動前は古い実装がメモリに残るため、再起動後に再確認してください。

rmmod algif_aeadを実行したので安全ですよね？

環境によっては安全ではありません。algif_aeadがカーネル組み込み（=y）の場合、コマンドは通っても実際には無効化されていません。本文の手順で組み込みかどうかを確認し、組み込みなら代替策を用いてください。

AlmaLinux・Rocky Linux・Debianも対象ですか？

2017年以降のカーネルを使う限り原則として対象です。各ベンダーがバックポート修正を順次配布しているため、CVE-2026-31431が明記されたエラータで対象パッケージを確認し適用してください。

dm-cryptやSSHは緩和策で止まりませんか？

止まりません。dm-crypt/LUKS・kTLS・IPsec・OpenSSL・SSHはAF_ALGを経由しないため、無効化・遮断の影響を受けません。

関連記事

• CI/CDパイプラインにおけるDocker脆弱性スキャンの重要性とその必要性
• コンテナ技術とは何か：仮想化との違いや基本概念を解説
• Dockerの基本的な概念と仕組みを理解する
• Kubernetesとは？初心者にもわかりやすく解説
• AKS（Azure Kubernetes Service）とは何かを徹底的に解説