--- title: "CVE-2026-31431（Copy Fail）とは｜影響カーネルの修正版と緩和策・確認手順" url: "https://www.issoh.co.jp/tech/details/11972/" published: 2026-04-30 updated: 2026-10-02 categories: ["脆弱性・インシデント"] publisher: "株式会社一創" --- # 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ほか）の影響範囲と対策](https://www.issoh.co.jp/tech/details/12089/)は、algif\_aeadを止めても防げません。Copy Failの暫定策だけで安心せず、両方の修正を含むカーネルへ更新してください。 ## CVE-2026-31431の正体とKEV追加までの公開経緯・深刻度の評価主体 Copy Failは、セキュリティ企業TheoriのTaeyang Lee氏が、同社のAI支援解析ツールXint Codeを使って見つけた欠陥です。[Theoriの技術解説（2026年4月29日公開）](https://xint.io/blog/copy-fail-linux-distributions)によると、2026年3月23日にカーネルのセキュリティチームへ報告され、4月1日に修正がメインラインへ入り、4月22日にCVEが採番されています。研究者による解説とPoCの公開は4月29日でした。 深刻度は[CVEレコード](https://www.cve.org/CVERecord?id=CVE-2026-31431)上で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](https://nvd.nist.gov/vuln/detail/CVE-2026-31431)は独自スコアを付けずCPEの解析だけを行っています。CVSSや脆弱性識別子の読み方は[CVEとCWEの違いと脆弱性管理の基礎](https://www.issoh.co.jp/tech/details/5119/)で整理しています。 悪用状況は明確です。[CISAのKEVカタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field%5Fcve=CVE-2026-31431)には2026年5月1日に追加され、連邦機関の対応期限は5月15日でした（2026年10月1日版カタログで確認）。[Red HatのセキュリティブリテンRHSB-2026-002](https://access.redhat.com/security/vulnerabilities/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の公式ブログ](https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available)、[Debianセキュリティトラッカー](https://security-tracker.debian.org/tracker/CVE-2026-31431)、[Red HatのCVEページ](https://access.redhat.com/security/cve/CVE-2026-31431)から取りました。 | ディストリ | 修正版（主系統） | | ------------------ | ------------------------ | | 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の使い分けとコンテナでの注意点](https://www.issoh.co.jp/tech/details/17895/)も参考になります。 ### 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カーネルを拡張する仕組み](https://www.issoh.co.jp/tech/details/13232/)、ルール運用は[Falcoのランタイム脅威検知とルール運用](https://www.issoh.co.jp/tech/details/17238/)で解説しています。侵害を疑う場合、再起動するとメモリ上の痕跡が消えるため、再起動の前にメモリの保全を検討してください。 ## 対処の優先順位：CIランナー・共有ホスト・Kubernetesノードから着手 工数が限られるなら、信頼できないコードを同じカーネルの上で動かす環境から直します。ページキャッシュはホスト全体で共有されるため、1つの侵害が同居する全員に及ぶからです。 - **CI/CDランナー**：セルフホスト型や共有ランナーは、悪意あるプルリクエストでコードが持ち込まれます。ジョブごとに使い捨てのVMへ切り替えると、改ざんが後続ジョブに残りません。 - **マルチテナントの共有ホスト**：SaaS基盤や共有ホスティングでは、1テナントの侵害がホストのrootに直結します。 - **Kubernetesノード**：TheoriはPodからホストへ抜ける手順も公開しています。ノードプール単位で版を確認します。 - **踏み台サーバー**：多数の本番系への鍵が集まり、侵害時の被害範囲が広くなります。 反対に、管理者だけがログインする単一用途のサーバーで、すでに修正版への更新予定が1週間以内に組まれているなら、緩和策を急いで入れる必要は薄いと判断します。initcall\_blacklistの再起動はカーネル更新の再起動と同じ停止を伴うため、その場合は更新を前倒しするほうが手戻りがありません。運用中のサーバー群のカーネル更新や構成の見直しを外部に任せたい場合は、[AWS・Google Cloud・Azureのインフラ構築・運用支援](https://www.issoh.co.jp/service/system/aws/)でも相談を受けています。 ## Copy Fail（CVE-2026-31431）の対応でよく寄せられる質問 運用現場から寄せられやすい疑問を、一次情報に沿って答えます。 ### リモートから直接攻撃される脆弱性ですか？ いいえ。CVSSの攻撃元区分はローカル（AV:L）で、サーバー上でコードを実行できる状態が前提です。ただしWebアプリの脆弱性やSSHアカウントの侵害で足がかりを得た攻撃者は、この欠陥で確実にrootへ昇格できます。CISAがKEVに追加したのは、実際の悪用が確認されたためです。 ### パッチを当てたのに検査で脆弱と出るのはなぜですか？ 多くは再起動前です。新しいカーネルはインストールしただけでは使われないため、`uname -r`で稼働中の版を確認してください。もう1つの原因は、版番号だけを見るスキャナーです。Red Hatはバックポートにより上流の版番号と一致しない点をCVEページで説明しており、パッケージ版で判断する必要があります。 ### rmmod algif\_aead を実行すれば安全になりますか？ 環境によります。RHEL系のように組み込みの場合、コマンドは何も起こさず終わり、防御になりません。Ubuntuのようにモジュール型でも、使用中なら取り外しに失敗します。本文の手順で組み込みか確認し、`/proc/modules`から消えたことまで確かめてください。 ### Ubuntu 26.04やRHEL 7は対象に含まれますか？ どちらも非該当です。Ubuntu 26.04（Resolute）は出荷時点で修正済みのカーネル7.0系を使い、Red HatはRHEL 6・7を非該当としています。ただし後続のDirty FragはUbuntu 26.04にも影響するため、別途確認が要ります。 ### Copy Failの緩和策でDirty Fragも防げますか？ 防げません。Dirty Fragの研究者は、algif\_aeadのブロックリストを適用した環境でもDirty Fragは成立すると明記しています。対象はesp4・esp6・rxrpcという別のモジュールで、対処も異なります。詳細は[Dirty Fragの3CVEと対策の解説](https://www.issoh.co.jp/tech/details/12089/)を参照してください。 ## 関連記事 - [Dirty Frag(CVE-2026-43284/43500/46300)とは｜Copy Fail 2の全体像とesp・rxrpc権限昇格の対策](https://www.issoh.co.jp/tech/details/12089/)：Copy Failの後に公開された同系統の3CVE - [カーネルとは？OSの中核が担う役割と仕組みを実装目線で解説【2026年版】](https://www.issoh.co.jp/tech/details/13534/)：ページキャッシュとカーネル空間の前提知識 - [Falcoとは？ランタイム脅威検知の仕組みとルール運用・誤検知の抑え方を解説](https://www.issoh.co.jp/tech/details/17238/)：AF\_ALGソケット作成の検知 - [Dockerの脆弱性診断をCI/CDに組み込む手順とツール選定](https://www.issoh.co.jp/tech/details/3795/)：CIランナー側の対策 - [Kubernetes（クバネティス）とは？仕組み・Dockerとの違い・読み方をわかりやすく解説](https://www.issoh.co.jp/tech/details/2928/)：ノードとPodの関係の整理 --- 出典: [CVE-2026-31431（Copy Fail）とは｜影響カーネルの修正版と緩和策・確認手順]()（株式会社一創）