公開2026.04.30更新2026.10.02 脆弱性・インシデント

CVE-2026-31431（Copy Fail）とは｜影響カーネルの修正版と緩和策・確認手順

CVE-2026-31431（通称Copy Fail）は、Linuxカーネルの暗号インターフェースalgif_aeadに潜むローカル権限昇格の脆弱性です。一般ユーザーの権限でsetuidバイナリのページキャッシュを書き換え、rootを取れます。影響はカーネル4.14以降と広く、CISAは2026年5月1日に悪用確認済み脆弱性カタログ（KEV）へ追加しました。本記事では、kernel.orgの系列別修正版と主要ディストリのパッケージ版、組み込み型とモジュール型で異なる緩和策、誤判定しない確認コマンドを、2026年10月2日時点の一次情報で整理します。

まとめ：Copy Failの影響範囲・修正版と今すぐ取るべき対応の結論

影響：カーネル4.14以降。系列ごとの修正版は5.10.254／5.15.204／6.1.170／6.6.137／6.12.85／6.18.22／6.19.12、7.0は修正済みで出荷。
深刻度：CVSS 3.1で7.8（kernel.org CNAとRed Hatの評価）。KEV追加は2026年5月1日、PoCとMetasploitモジュールが公開済み。
恒久対策：ディストリの修正版カーネルへ更新し、再起動する。インストールしただけでは直らない。
暫定策：Ubuntuなどalgif_aeadがモジュールの環境はロード禁止、RHEL系の組み込み環境は起動引数initcall_blacklist。止め方を取り違えると、コマンドは通るのに無防備のまま残る。
優先順位：CI/CDランナー、共有ホスト、Kubernetesノード、踏み台サーバーから着手する。

なお2026年5月7日以降に公開された後続のDirty Frag（CVE-2026-43284ほか）の影響範囲と対策は、algif_aeadを止めても防げません。Copy Failの暫定策だけで安心せず、両方の修正を含むカーネルへ更新してください。

CVE-2026-31431の正体とKEV追加までの公開経緯・深刻度の評価主体

Copy Failは、セキュリティ企業TheoriのTaeyang Lee氏が、同社のAI支援解析ツールXint Codeを使って見つけた欠陥です。Theoriの技術解説（2026年4月29日公開）によると、2026年3月23日にカーネルのセキュリティチームへ報告され、4月1日に修正がメインラインへ入り、4月22日にCVEが採番されています。研究者による解説とPoCの公開は4月29日でした。

深刻度はCVEレコード上でCVSS 3.1の7.8（AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H）です。この値はkernel.orgのCNAとRed Hatが付けたもので、NVDは独自スコアを付けずCPEの解析だけを行っています。CVSSや脆弱性識別子の読み方はCVEとCWEの違いと脆弱性管理の基礎で整理しています。

悪用状況は明確です。CISAのKEVカタログには2026年5月1日に追加され、連邦機関の対応期限は5月15日でした（2026年10月1日版カタログで確認）。Red HatのセキュリティブリテンRHSB-2026-002の時系列には、4月29日にMetasploitモジュールが公開されたことも記録されています。単体ではリモートから悪用できず、Webアプリの侵害やSSHの足がかりなど、初期侵入の後にrootへ昇格する段で使われます。

Dirty Cow・Dirty Pipeと比べたCopy Failの決定論的な成立条件

過去の著名な権限昇格と比べた違いは、レース条件を必要としない点です。Theoriは732バイトのPythonスクリプトが、配布形態やカーネル版ごとのオフセット調整なしに複数ディストリで動いたと報告しています。

項目	Dirty Cow	Dirty Pipe	Copy Fail
CVE	CVE-2016-5195	CVE-2022-0847	CVE-2026-31431
成立条件	COW経路のレース	パイプバッファ操作	暗号APIの論理欠陥
成功の確実性	再試行が要る	版依存あり	決定論的
ディスク上のファイル	書き換わる	書き換わらない	書き換わらない

Theoriが実機でrootを取ったと示した組み合わせは、Ubuntu 24.04 LTS（6.17.0-1007-aws）、Amazon Linux 2023（6.18.8）、RHEL 10.1（6.12.0-124.45.1）、SUSE 16（6.12.0-160000.9）の4つです。

algif_aeadとsplice・authencesnが連動する4バイト書き込みの仕組み

原因は単一のバグではなく、別々の時期に入った3つの変更の交差です。AF_ALGは、非特権ユーザーがカーネルの暗号処理を呼べるソケットで、そのAEAD版がalgif_aeadです。splice()を使うと、ファイルのページキャッシュ（ファイル内容を保持するメモリ上の共有キャッシュ）を参照のまま暗号処理へ渡せます。

2017年、algif_aeadに入出力を同じバッファで処理するin-place化（コミット72548b093ee3）が入りました。このとき認証タグ部分のページが参照のまま出力側へ連結され、spliceで渡したページキャッシュが書き込み先に混ざる経路ができています。最後の引き金が、IPsecの拡張シーケンス番号用テンプレートauthencesnです。GCMやCCM、通常のauthencは出力範囲の外に書きませんが、authencesnは作業領域として出力境界の外へ4バイトを書きます。

結果として、攻撃者は読める任意のファイル（典型は/usr/bin/su）の、選んだ位置の4バイトを、選んだ値に書き換えられます。ページはダーティ扱いにならないためディスク上のファイルは変わらず、再起動やキャッシュ破棄で改ざんは消えます。修正（コミットa664bf3d603d）はalgif_aeadをout-of-place動作へ戻し、ページキャッシュが書き込み先に入る経路そのものを塞ぎました。

影響を受けるカーネル系列と主要ディストリ別の修正版一覧（2026年10月時点）

影響範囲の判断を誤りやすいのは、ディストリのカーネルが上流の版番号どおりではない点です。上流の系列で見る表と、パッケージで見る表を分けて示します。

kernel.orgの安定版系列ごとの修正版と影響開始バージョン4.14

kernel.org CNAのCVEレコードでは、4.14で混入し、次の版で修正されています。各系列でこの版未満が影響対象です。

系列	修正版
5.10系	5.10.254
5.15系	5.15.204
6.1系	6.1.170
6.6系	6.6.137
6.12系	6.12.85
6.18系／6.19系	6.18.22／6.19.12
7.0以降	修正済みで出荷

4.14より前の系列は非該当です。上流の版番号で判定してよいのは、自前ビルドのカーネルや上流に追従するディストリ（Arch、Fedoraなど）に限られます。

Ubuntu・Debian・RHELのパッケージ単位で見た修正版の早見表

Ubuntu・Debian・RHELは修正をバックポートするため、パッケージの版で判断します。数値はCanonicalの公式ブログ、Debianセキュリティトラッカー、Red HatのCVEページから取りました。

ディストリ	修正版（主系統）
Ubuntu 24.04	6.8.0-117.117
Ubuntu 22.04	5.15.0-179.189
Ubuntu 20.04	5.4.0-230.250
Ubuntu 26.04	非該当
Debian 12 bookworm	6.1.170-1
Debian 13 trixie	6.12.85-1
RHEL 9.7	5.14.0-611.54.1.el9_7
RHEL 8.10	4.18.0-553.123.1.el8_10
RHEL 10.1	6.12.0-124.55.1.el10_1

Ubuntuのクラウド向け・HWEカーネルは別の版番号になります（24.04のHWEは6.17.0-29.29~24.04.1）。RHEL 6・7は非該当です。Amazon Linux 2023とSUSEは、ALASとSUSE-SUの各アドバイザリでCVE-2026-31431を含む版を確かめてください。

自社サーバーが対象かを稼働カーネルとパッケージ版で確かめる手順

判定の対象はホストOSのカーネルです。コンテナはホストのカーネルを共有するため、コンテナイメージを更新してもホストが古ければ攻撃は通ります。版の読み方はos-releaseとunameの使い分けとコンテナでの注意点も参考になります。

algif_aeadの組み込み・モジュール判定と設定ファイルの確認

緩和策の選び方が変わるため、最初に稼働中のカーネル設定ファイルを確認し、algif_aeadが組み込みかモジュールかを判定します。WSL2のように/boot/config-$(uname -r)が存在しない環境もあるので、/proc/config.gzへ切り替える形にしてあります。

# 稼働中のカーネルとディストリ
uname -r
grep -E '^(NAME|VERSION)=' /etc/os-release

# algif_aead が組み込み(=y)かモジュール(=m)か
cfg=/boot/config-$(uname -r)
if [ -r "$cfg" ]; then grep CONFIG_CRYPTO_USER_API_AEAD "$cfg"
else zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API_AEAD; fi

# モジュールとして読み込まれているか
grep -E '^algif_aead ' /proc/modules || echo "algif_aead は読み込まれていない"

WSL2のUbuntu 26.04（カーネル6.18.33.2）でこの手順を実行すると、CONFIG_CRYPTO_USER_API_AEAD=mと表示されました。Ubuntuがロード禁止の暫定策をkmodパッケージで配布したのも、モジュール型だからです。一方、Red HatはRHELでは組み込みのためブロックリストできないと明記しています。

版番号の比較で誤判定しないためのdpkg・rpmでの修正確認コマンド

旧版で紹介していたapt changelog linux-image-$(uname -r)は使わないでください。Ubuntu 26.04で実測したところ、linux-imageの変更履歴は署名パッケージ（linux-signed）のものでCVE番号が1件も載っておらず、Debianでは取得自体が失敗しました。パッケージの版を修正版と比べる方法が確実です。

# Ubuntu / Debian：稼働中カーネルのパッケージ版を修正版と比較する
pkgver=$(dpkg-query -W -f='${Version}' "linux-image-$(uname -r)")
fixed=6.8.0-117.117   # 自分のリリースの修正版に置き換える（例は Ubuntu 24.04）
dpkg --compare-versions "$pkgver" ge "$fixed" && echo "修正版以上: $pkgver" || echo "修正版未満: $pkgver"

# Ubuntu で変更履歴を見るなら linux-modules 側（CVE 番号が記載される）
apt changelog "linux-modules-$(uname -r)" | grep -m1 CVE-2026-31431

# RHEL / Rocky / AlmaLinux 8〜10：稼働中カーネルに限定して照会する
rpm -q --changelog "kernel-core-$(uname -r)" | grep -m1 CVE-2026-31431

dpkgの比較はDebianの版規則（~や-の扱い）に従うため、sort -Vでの文字列比較より安全です。RHEL系の変更履歴には{CVE-2026-31431}の形でCVE番号が入ることを、AlmaLinux 9のkernel-coreで確かめました。rpm -q --changelog kernelのように名前だけで照会すると、インストール済みで未起動の新しいカーネルの記録まで拾い、再起動前なのに「修正済み」と誤認します。

恒久対策としてのカーネル更新と再起動・ライブパッチの使い分け

根本対策は修正版カーネルへの更新と再起動です。新しいカーネルはインストールしただけでは使われません。

# Ubuntu：カーネルのメタパッケージを含めて更新し、再起動する
sudo apt update && sudo apt upgrade
sudo reboot

# RHEL / Rocky / AlmaLinux / Amazon Linux 2023
sudo dnf update kernel
sudo reboot

# SUSE
sudo zypper patch
sudo reboot

再起動後、uname -rの結果が前章の修正版以上になったことを確認して完了です。すぐに再起動できない本番機では、Canonical Livepatch、Red Hatのkpatch（RHEL 8・9向けにkpatch-patchが2026年5月11日以降配布）、SUSEのLive Patchingで修正を先に当てられます。ライブパッチは次回の計画停止までのつなぎと位置づけ、停止枠では正規のカーネル更新を済ませます。

マネージドKubernetesでも、ワーカーノードのOSイメージ更新は利用者の操作や自動アップグレード設定に左右されます。ノードプールごとにカーネル版を確認し、未対応ならパッチ済みイメージへ入れ替えてください。EC2やCompute Engineなど自前で管理する仮想マシンは、利用者側の更新が前提です。

更新できない間の緩和策：モジュール型と組み込み型で異なる止め方

緩和策は時間稼ぎです。前章の判定で=mなら次の1つ目、=yなら2つ目を使います。逆を選ぶと、エラーを出さずに終わるのに防げていない状態になります。

Ubuntuなどモジュール型でalgif_aeadのロードを止める手順と確認

Canonicalが公開している手動手順です。Ubuntuでは公開当日にkmodパッケージの更新（USN-8226-1）で同じ設定が配布され、修正版カーネルの提供後はこの暫定策を取り消す方針が示されています。

# 1. 今後の読み込みを禁止する
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/manual-disable-algif_aead.conf
# 2. 読み込み済みなら取り外す（使用中なら失敗する）
sudo rmmod algif_aead 2>/dev/null
# 3. 外れたかを確かめる。残っていれば再起動する
grep -qE '^algif_aead ' /proc/modules && echo "まだ読み込まれている" || echo "読み込まれていない"

Canonicalは、algif_aeadを止めると一部のアプリがユーザー空間の暗号処理へ切り替わらない可能性があると注意しています。修正版カーネルへ更新した後は、作成した設定ファイルを削除して元に戻します。

RHEL系の組み込み型でinitcall_blacklistを起動引数に加える方法

組み込みの環境ではmodprobe.dもrmmodも効きません。Red Hatは起動引数で初期化関数を止める方法を案内しており、適用には再起動が要ります。

# 全カーネルの起動引数に追加する（RHEL 8〜10）
sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot
# 再起動後に反映を確認する
grep -o 'initcall_blacklist=[^ ]*' /proc/cmdline

Red Hatは代替として、AF_ALG全体を止めるinitcall_blacklist=af_alg_initと、原因のテンプレートだけを止めるinitcall_blacklist=crypto_authenc_esn_module_initも示しています。後者はIPsecでESNを使う構成に影響しうるため、IPsec VPNを動かすホストでは1つ目を選ぶのが無難です。修正版へ更新した後はgrubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"で外します。

AF_ALG遮断で影響を受ける機能と影響を受けない暗号処理の切り分け

信頼できないコードを動かすコンテナやCIランナーでは、seccompでsocket()の第1引数がAF_ALG（値38）の呼び出しを拒否する方法もあります。ホスト全体の設定を変えずに済むのが利点です。止めて困る範囲は狭く、次のとおりです。

機能	影響	理由
dm-crypt／LUKS	なし	カーネル内の暗号APIを直接使う
IPsec（xfrm）	なし	カーネル内で処理する
OpenSSL・SSH	通常なし	ユーザー空間で完結
afalgエンジン利用	あり	AF_ALGを経由する

影響が出るのは、OpenSSLのafalgエンジンを有効にした構成や、ハードウェア暗号オフロードをAF_ALG経由で使うアプリに限られます。心配なら、止める前に次章のauditdルールで30分ほどAF_ALGの利用者がいないかを記録してから判断します。

ファイル改ざん検知をすり抜ける理由とauditd・eBPFでの監視設計

改ざんはページキャッシュ上で起き、ディスク上のファイルは変わりません。AIDEやTripwireのようにディスク上のチェックサムを比べる仕組みは、再起動やキャッシュ破棄の後に正常と判定します。inotifyやauditdのファイル監視（-w）も通常の書き込み経路を見る設計のため反応しません。

そこで、攻撃の前段であるAF_ALGソケットの作成を記録します。通常の業務サーバーではほぼ発生しない呼び出しです。

# /etc/audit/rules.d/af_alg.rules（64bit の例）
-a always,exit -F arch=b64 -S socket -F a0=38 -k AF_ALG_SOCKET
# 32bit プロセスも見るなら socketcall 経由になるため arch=b32 のルールを別に足す

# 反映と確認
sudo augenrules --load
sudo ausearch -k AF_ALG_SOCKET -i | tail -20

コンテナやKubernetesの規模で見るなら、eBPFベースのランタイム監視が向いています。仕組みはeBPFでLinuxカーネルを拡張する仕組み、ルール運用はFalcoのランタイム脅威検知とルール運用で解説しています。侵害を疑う場合、再起動するとメモリ上の痕跡が消えるため、再起動の前にメモリの保全を検討してください。

対処の優先順位：CIランナー・共有ホスト・Kubernetesノードから着手

工数が限られるなら、信頼できないコードを同じカーネルの上で動かす環境から直します。ページキャッシュはホスト全体で共有されるため、1つの侵害が同居する全員に及ぶからです。

CI/CDランナー：セルフホスト型や共有ランナーは、悪意あるプルリクエストでコードが持ち込まれます。ジョブごとに使い捨てのVMへ切り替えると、改ざんが後続ジョブに残りません。
マルチテナントの共有ホスト：SaaS基盤や共有ホスティングでは、1テナントの侵害がホストのrootに直結します。
Kubernetesノード：TheoriはPodからホストへ抜ける手順も公開しています。ノードプール単位で版を確認します。
踏み台サーバー：多数の本番系への鍵が集まり、侵害時の被害範囲が広くなります。

反対に、管理者だけがログインする単一用途のサーバーで、すでに修正版への更新予定が1週間以内に組まれているなら、緩和策を急いで入れる必要は薄いと判断します。initcall_blacklistの再起動はカーネル更新の再起動と同じ停止を伴うため、その場合は更新を前倒しするほうが手戻りがありません。運用中のサーバー群のカーネル更新や構成の見直しを外部に任せたい場合は、AWS・Google Cloud・Azureのインフラ構築・運用支援でも相談を受けています。

Copy Fail（CVE-2026-31431）の対応でよく寄せられる質問

運用現場から寄せられやすい疑問を、一次情報に沿って答えます。

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

いいえ。CVSSの攻撃元区分はローカル（AV:L）で、サーバー上でコードを実行できる状態が前提です。ただしWebアプリの脆弱性やSSHアカウントの侵害で足がかりを得た攻撃者は、この欠陥で確実にrootへ昇格できます。CISAがKEVに追加したのは、実際の悪用が確認されたためです。

パッチを当てたのに検査で脆弱と出るのはなぜですか？

多くは再起動前です。新しいカーネルはインストールしただけでは使われないため、uname -rで稼働中の版を確認してください。もう1つの原因は、版番号だけを見るスキャナーです。Red Hatはバックポートにより上流の版番号と一致しない点をCVEページで説明しており、パッケージ版で判断する必要があります。