CVE-2026-31431（Copy Fail）とは｜ディストリ別の修正版・GKEとEKSの対応と緩和策

CVE-2026-31431（通称Copy Fail）は、Linuxカーネルの暗号インターフェースalgif_aeadに潜むローカル権限昇格の脆弱性です。一般ユーザーの権限でsetuidバイナリのページキャッシュを書き換え、rootを取れます。影響はカーネル4.14以降と広く、CISAは2026年5月1日に悪用確認済み脆弱性カタログ（KEV）へ追加しました。本記事では、RHEL・Rocky Linux・AlmaLinux・Ubuntu・Amazon Linuxなどの修正版、GKE・EKS・Fargateの対応状況、組み込み型とモジュール型で異なる緩和策を、2026年11月3日時点の一次情報で整理します。

まとめ：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日、732バイトのPoCとMetasploitモジュールが公開済み。
• 修正版：AlmaLinuxは2026年5月1日、RHEL・Rocky Linux・Oracle LinuxのRHEL互換カーネルは5月4〜6日に配布。Ubuntu・Debian・Amazon Linux・SUSEも配布済みで、提供日はカーネル系統ごとに異なる。半年たった今も未更新なら、それ自体が要対応の状態。
• クラウド：GKEはContainer-Optimized OSのノードプールを修正版へ上げる。EKS・ECS on EC2は最新AMIへ、AKSは修正済みノードイメージへ入れ替える。Fargateは基盤側で修正済み。
• 暫定策：Ubuntuなどalgif_aeadがモジュールの環境はロード禁止、RHEL系の組み込み環境は起動引数initcall_blacklist。止め方を取り違えると、コマンドは通るのに無防備のまま残る。更新後は外す。

なお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は独自スコアを付けていません。CVSSや脆弱性識別子の読み方はCVEとCWEの違いと脆弱性管理の基礎で整理しています。

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

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

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

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

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

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

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

公開PoC（copy_fail_exp.py）の中身と検証環境で扱うときの注意

Theoriは公開当日にGitHubのtheori-io/copy-fail-CVE-2026-31431へPoCを置きました。リポジトリの中身はREADMEとcopy_fail_exp.py（732バイト）の2ファイルだけです。スクリプトを読むと、標準ライブラリのos・zlib・socketしか読み込まず、AF_ALG（38）のソケットでauthencesn(hmac(sha256),cbc(aes))を指定し、spliceで/usr/bin/suのページキャッシュを書き換える作りです。追加のPythonパッケージは不要ですが、os.spliceを使うためPython 3.10以降が必要で、脆弱なLinuxカーネルと対象の暗号APIへアクセスできる構成が前提です。

READMEが動作確認先として挙げるのは、Ubuntu 24.04 LTS（6.17.0-1007-aws）、Amazon Linux 2023（6.18.8-9.213.amzn2023）、RHEL 10.1（6.12.0-124.45.1.el10_1）、SUSE 16（6.12.0-160000.9-default）の4つです。GitHub上には、C言語への移植版や「脆弱かどうか判定する」と称するスクリプトも多数出回っています。

パッチの効果を確かめる目的でも、PoCを本番機や共用機で動かすのは避けてください。成功すると、そのホスト上のすべての利用者が使うsuのメモリ上のコピーが壊れた状態で残ります。検証は使い捨てのVMで行い、終わったらVMごと破棄するか、少なくとも再起動してページキャッシュを捨てます。出所の不明な移植版や判定スクリプトは、実行前に中身を読んでください。修正の確認だけなら、後述のパッケージ版の比較で足ります。

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

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

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

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

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

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

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

Ubuntuのクラウド向けカーネルは別の版番号です。24.04ではlinux-awsが6.8.0-1055.58、linux-gcpが6.8.0-1058.61、linux-azureが6.8.0-1056.62、Raspberry Pi向けのlinux-raspiが6.8.0-1056.60で修正されています。Ubuntuは公開当日にkmodパッケージの更新（USN-8226-1）でalgif_aeadのロード禁止を先に配っており、カーネルの修正はその後のUSNで届いています。

RHEL・Rocky Linux・AlmaLinux・Oracle Linuxの修正版とアドバイザリ番号

次の表はRHEL互換カーネルの修正版です。AlmaLinuxの先行修正版とOracle LinuxのUEKは表の後で扱います。RHELはRed HatのCVEページ、RockyはRocky Linuxのerrata、OracleはOracle LinuxのCVEページで確認しました。

AlmaLinuxは、Red Hatの修正を待たずに2026年5月1日に独自ビルドを出しました。AlmaLinuxのerrataでは、ALSA-2026:A001（8：4.18.0-553.121.1.el8_10）、ALSA-2026:A002（9：5.14.0-611.49.2.el9_7）、ALSA-2026:A003（10：6.12.0-124.52.2.el10_1）が該当し、その後RHELと同じ版（ALSA-2026:13577／13565／13566）も配布されています。Red Hat系より版番号が小さくても修正済みのことがあるので、AlmaLinuxは版の大小ではなくアドバイザリの適用有無で判断します。

Oracle LinuxのUEK（Unbreakable Enterprise Kernel）は別系統で、5月1日のELSA-2026-50255（Oracle Linux 8のUEK R6：5.4.17-2136.354.4.2）、ELSA-2026-50253（9のUEK R7：5.15.0-319.201.4.4）、ELSA-2026-50254（9・10のUEK R8：6.12.0-201.74.2.2）が修正版です。RHEL 8.4・8.6・8.8や9.0・9.2・9.4・9.6のEUS系にも個別の修正版があり、RHEL 6・7は非該当です。CentOS 7は3.10系のカーネルで非該当ですが、4.18系のCentOS 8やCentOS Stream 8はサポートが終わっているため、影響を受けるのに修正が届きません。移行先の選び方はCentOS終了後のRHEL互換OSと後継の選び方で整理しています。

Amazon Linux・SUSE・Arch Linuxの修正状況

Amazon LinuxのCVEページでは、2026年5月5日付で次のアドバイザリが出ています。

Amazon Linuxのライブパッチ（kernel-livepatch）は5月4日から配られています。SUSEはSUSEのCVEページのとおり5月2日から修正を出しており、SLES 15 SP7はSUSE-SU-2026:1669-1（kernel-default 6.4.0-150700.53.40.1）、SP6 LTSSはSUSE-SU-2026:1671-1（6.4.0-150600.23.100.1）、SLES 16.0はSUSE-SU-2026:21439-1（6.12.0-160000.29.1）が該当します。zypper patchで入ります。

上流追従型のArch Linuxは、AVG-2908でlinuxパッケージ6.19.12-1を修正版としています。Raspberry Pi公式のカーネルは、5月2日にrpi-6.12.yとrpi-6.18.yの両ブランチへ修正が入りました。Androidは、AOSPのSELinuxポリシーが一般アプリにAF_ALGのソケット（alg_socket）の作成を禁じているため、通常のアプリからは同じ経路に届きにくい構成です。ただし端末ごとのカーネル構成は異なるので、影響の有無はメーカーのセキュリティ更新で確かめてください。

GKE・EKS・AKS・Fargateなどマネージド環境の対応状況

マネージドKubernetesやコンテナ基盤では、利用者がノードを更新しないと直らないものと、基盤側で済んでいるものが混在します。

GKEのセキュリティ情報GCP-2026-026は、StandardとAutopilotの両方を影響ありとし、GKE Sandboxで動くコンテナは影響を受けないとしています。2026年5月4日の更新で、Container-Optimized OSのノードプール向けに次の修正版が示されました。GKEのAutopilotとStandardの違いでいうと、Standardはノードプールを、Autopilotはコントロールプレーンをこの版以上へ上げます。

同じ速報でGoogleは、コンテナを安全境界として頼らないよう勧め、分離が要るワークロードにはGKE Sandboxを推しています。GKE SandboxはgVisorのサンドボックス上でコンテナを動かし、ホストのカーネルへ直接システムコールを届けない構成です。

AWSはセキュリティ速報2026-030-AWS（最終更新2026年6月17日）で、Copy Failについて次のように整理しています。

• EKS：EKS最適化AMIの修正版が公開済み。ノードグループを新しいAMIへ入れ替える。
• ECS：ECS on EC2とECS Managed Instancesに更新が出ている。利用者側で適用する。
• Fargate：プラットフォーム1.3と1.4の両方で修正済み。
• Bottlerocket：サポート中の全版に更新が出ている（v1.60.0でkernel-6.1・6.12・6.18に修正を適用）。
• SageMaker：2026年5月15日以降に作成・再起動したノートブックやエンドポイントは修正済みのカーネルで動く。

AzureのAKSの公式案内では、Ubuntu 22.04ノードはVHD 202606.08.1（カーネル5.15.0-1114.123）、Ubuntu 24.04ノードは同じく202606.08.1（6.8.0-1059.65）、Azure Linux 3ノードは202605.27.0（6.6.139.1-1.azl3）以上のノードイメージが修正済みです。これらの最低版は対応する標準カーネル系統に限られます。Azure NVIDIAカーネル、OSGuard、Kataゲストカーネルなどへ流用せず、稼働カーネルを確認したうえでノードイメージを更新します。

EC2やCompute Engineなど自前で管理する仮想マシンは、利用者側の更新が前提です。マネージドでも、5月以前に作ったノードを入れ替えずに使い続けている場合は旧カーネルのままなので、ノードごとに版を確認してください。

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

判定の対象はホスト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 は読み込まれていない"

Ubuntuがロード禁止の暫定策をkmodパッケージで配布したのは、Ubuntuのカーネルでalgif_aeadがモジュール（=m）だからです。一方、Red HatはRHELでは組み込みのためブロックリストできないと明記しています。

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

apt changelog linux-image-$(uname -r)は使わないでください。Ubuntuのlinux-imageの変更履歴は署名パッケージ（linux-signed）のもので、CVE番号が載りません。パッケージの版を修正版と比べる方法が確実です。

# Ubuntu / Debian：稼働中カーネルのパッケージ版を修正版と比較する
fixed=6.8.0-117.117   # 自分のリリースの修正版に置き換える（例は Ubuntu 24.04）
if pkgver=$(dpkg-query -W -f='${Version}' "linux-image-$(uname -r)" 2>/dev/null); then
  dpkg --compare-versions "$pkgver" ge "$fixed" && echo "修正版以上: $pkgver" || echo "修正版未満: $pkgver"
else
  echo "パッケージ版を取得できない（自前ビルドなど）ため判定しない"
fi

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

# RHEL / Rocky / AlmaLinux / Oracle Linux 8〜10：稼働中カーネルを持つパッケージに限定して照会する（UEK も可）
rpm -qf --changelog "/lib/modules/$(uname -r)/vmlinuz" | grep -m1 CVE-2026-31431

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

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

根本対策は修正版カーネルへの更新と再起動です。新しいカーネルはインストールしただけでは使われません。ローカル権限昇格のCopy Failと違い、ネットワーク越しに認証なしで届くカーネルの脆弱性もあります。修正版の見分け方と更新までの緩和策はLinuxカーネルの脆弱性CVE-2026-98432の修正版とnftablesの緩和策で解説しています。

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

# RHEL / Rocky / AlmaLinux / Oracle Linux（UEK と関連モジュールも含める）
sudo dnf update 'kernel*'
sudo reboot

# Amazon Linux 2023：リポジトリが版で固定されるため、修正を含むリリースを指定して上げる
sudo dnf check-release-update                # 利用できるリリース番号を表示する
sudo dnf upgrade --releasever=2023.12.20261021   # 検証済みの番号に置き換える（例）
sudo reboot

# SUSE
sudo zypper patch
sudo reboot

再起動後、uname -rで稼働カーネルを特定し、前章の手順で対応するパッケージ版と公式アドバイザリを照合して完了です。すぐに再起動できない本番機では、Canonical Livepatch、Red Hatのkpatch（RHEL 8・9向けのkpatch-patchが2026年5月11日以降配布）、Amazon Linuxのkernel-livepatch、SUSEのLive Patchingで修正を先に当てられます。ライブパッチは次回の計画停止までのつなぎと位置づけ、停止枠では正規のカーネル更新を済ませます。

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

緩和策は時間稼ぎです。前章の判定で=mなら次の1つ目、=yなら2つ目を使います。方式を取り違えると、設定ファイルの作成に成功しても防御にならなかったり、取り外しに失敗したりします。

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

Canonicalの公式ブログが示す手動手順です。

# 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つ目を選ぶのが無難です。

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

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

影響が出るのは、OpenSSLのafalgエンジンを有効にした構成や、ハードウェア暗号オフロードをAF_ALG経由で使うアプリに限られます。停止前には、次章のauditdルールによる観測に加え、定期ジョブやアプリの設定も確認します。短時間の観測で呼び出しがなくても、未使用とは断定できません。

修正版へ更新した後に暫定策を外す手順

暫定策を残したままにすると、afalgエンジンを使うアプリが動かない原因になり、後任者には理由が分かりません。修正版カーネルで再起動したことを確かめてから外します。

# Ubuntu：作成した設定ファイルを消し、読み込めることを確かめる
sudo rm /etc/modprobe.d/manual-disable-algif_aead.conf
sudo modprobe algif_aead && echo "読み込める"

# RHEL 系：起動引数から外して再起動し、消えたことを確かめる
sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot
grep -c initcall_blacklist /proc/cmdline

Ubuntuのkmod更新で自動配布されたロード禁止は、修正版カーネルの提供後に取り消す方針がCanonicalから示されています。自分で作ったファイルだけを消してください。

ファイル改ざん検知をすり抜ける理由と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 の監視は対象ABIに合わせて追加する。x86-32では直接のsocketと従来のsocketcallの両経路に注意する

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

もう1つの手がかりは攻撃の最終段です。公開PoCは書き換えたsuを起動してrootを取るため、Palo Alto NetworksのUnit 42は、一般ユーザーがシェルやsudo以外の親プロセスからsuを起動する動きを狩る検知クエリを公開しています。コンテナやKubernetesの規模で見るなら、eBPFベースのランタイム監視が向いています。仕組みはeBPFでLinuxカーネルを拡張する仕組み、ルール運用はFalcoのランタイム脅威検知とルール運用で解説しています。侵害を疑う場合、再起動するとメモリ上の痕跡が消えるため、再起動の前にメモリの保全を検討してください。

Copy FailとDirty Fragの違いと両方を塞ぐ更新の考え方

「dirty flag」「copy fail 2」で検索されるDirty Fragは、Copy Failの8日後に別の研究者が公開した同系統の欠陥です。ページキャッシュを書き換える点は同じですが、通り道のモジュールが違います。

3件目のCVE-2026-46300（通称Fragnesia）はESP-in-TCP（espintcp）を通る後続の欠陥で、Dirty Fragの記事でまとめて扱っています。緩和策は別々に要りますが、恒久対策はどちらもカーネル更新です。Copy Failの修正だけを含む5月上旬のカーネルで止まっているホストは、Dirty Fragに対して未修正のままです。両方の修正を含む版と各CVEの暫定策はDirty Fragの3CVEと対策の解説で確認してください。

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

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

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

反対に、信頼できないコードの実行経路を遮断でき、カーネル更新を直ちに実施できるサーバーでは、再起動を伴う暫定策より修正版への更新を優先します。initcall_blacklistの再起動はカーネル更新の再起動と同じ停止を伴うため、その場合は更新を前倒しするほうが手戻りがありません。運用中のサーバー群のカーネル更新や構成の見直しを外部に任せたい場合は、AWS・Google Cloud・Azureのインフラ構築・運用支援でも相談を受けています。

よくある質問：Copy Fail（CVE-2026-31431）の対応

以下では、攻撃の前提、修正確認、ディストリ別の判定で迷いやすい点を整理します。

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

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

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

多くは再起動前です。新しいカーネルはインストールしただけでは使われないため、uname -rで稼働中の版を確認してください。もう1つの原因は、版番号だけを見るスキャナーです。RHEL系もUbuntuもバックポートで修正しているため、上流の版番号では判定できません。パッケージ版で判断します。

Rocky LinuxやAlmaLinuxはRHELと同じ版で判断できますか？

Rocky Linuxは同じ版です（8.10なら4.18.0-553.123.1.el8_10以上）。AlmaLinuxは5月1日の独自ビルドがRHELより小さい版番号（8なら4.18.0-553.121.1.el8_10）で修正済みのため、版の大小で比べると誤判定します。ALSA-2026:A001〜A003か、RHELと同番号のALSAが適用されているかで見てください。

rmmod algif_aead を実行すれば安全になりますか？

環境によります。RHEL系のように組み込みの場合、rmmodは取り外しに失敗し、防御になりません。Ubuntuのようにモジュール型でも、使用中なら取り外しに失敗します。本文の手順で組み込みか確認し、/proc/modulesから消えたことまで確かめてください。

Ubuntu 26.04やRHEL 7は対象に含まれますか？

どちらも非該当です。Ubuntu 26.04（Resolute）は出荷時点で修正済みのカーネル7.0系を使い、Red HatはRHEL 6・7を非該当としています。ただし後続のDirty FragはUbuntu 26.04にも影響するため、別途確認が要ります。

関連記事

• Dirty Frag(CVE-2026-43284/43500/46300)とは｜Copy Fail 2の影響範囲と修正版・緩和策
• カーネルとは？OSの中核が担う役割と仕組みを実装目線で解説【2026年版】
• Falcoとは？ランタイム脅威検知の仕組みとルール運用・誤検知の抑え方を解説
• Dockerの脆弱性診断をCI/CDに組み込む手順｜Trivy・Docker Scout・Grypeの終了コードと結果の直し方
• Kubernetes（クバネティス）とは？仕組み・メリット・デメリットとDockerとの違いをわかりやすく解説