AIが浮上させたLinux kernel脆弱性 “Copy Fail”：CVE-2026-31431の影響範囲と対応ガイド¶

対象 / ポイント

対象: Linuxサーバ、Kubernetes node、コンテナホスト、CI runner、共有開発サーバ、踏み台サーバ、notebook / sandbox環境を運用しているエンジニア、SRE、情シス、セキュリティ担当者。

ポイント:

CVE-2026-31431 “Copy Fail” は、Critical RCEではなくHighのローカル権限昇格脆弱性
優先確認対象は、低権限コードが動くKubernetes node、CI runner、sandbox、共有サーバ
恒久対応は修正版kernelへの更新と再起動、暫定策は algif_aead 無効化やAF_ALG制限

Kubernetes nodeやself-hosted CI runnerで低権限コードが動くなら、CVE-2026-31431は早めに確認すべきLinux kernel脆弱性です。

通称 Copy Fail と呼ばれるこの問題は、Linux kernelの crypto/ サブシステム、AF_ALG、splice()、page cacheが組み合わさって起きるローカル権限昇格です。 Theori / Xintの公開情報では、Xint CodeがLinux crypto/ サブシステムを約1時間スキャンし、発見候補として浮上させたと説明されています¹².

ただし、これは「AIが完全自律でLinux kernelを攻略した」という単純な話ではありません。 Xintの説明では、Linux crypto subsystemとpage-cache-backed dataの相互作用を見ていた人間研究者の洞察が起点にあります².

この記事の問いは、AIによる発見プロセスを過大評価せず、運用者がどのLinuxホストから対応すべきかを判断することです。

まず見るべきはCritical RCEかどうかではない¶

CVE-2026-31431は、インターネット越しに単体で侵入される脆弱性ではありません。

NVDは2026年4月30日時点で “Awaiting Enrichment” ですが、kernel.org CNAのCVSS 3.1は 7.8 High です。 Vectorは AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H で、攻撃元はLocal、必要権限はLow、ユーザー操作は不要と評価されています³.

実務上の意味は明確です。

すでにLinuxホスト上で低権限コードを実行できる攻撃者が、root権限へ昇格できる可能性がある。

つまり、最初の問いは「Linuxを使っているか」だけでは足りません。そのLinuxホスト上で、信頼できない低権限コードが動く可能性があるか が対応優先度を決めます。

影響範囲は3つの質問で切る¶

最初に見る対象は、コンテナイメージやアプリケーションではなく、起動中のホストkernelです。

KubernetesならPodのベースイメージではなくworker nodeを確認します。CIならジョブコンテナではなくrunner hostを確認します。最低限、対象ホストで次を見ます。

cat /etc/os-release
uname -r

ただし、uname -r の数字だけで最終判断してはいけません。ディストリビューションは、上流kernelのバージョン番号を大きく変えずにセキュリティ修正をバックポートすることがあります。

質問	見るべきもの	優先度が上がる例
対象はLinuxホストか	起動中のkernel	Linux VM、物理サーバ、Kubernetes worker node
低権限コードが動くか	ログインユーザー、CI job、Pod、利用者コード	共有開発サーバ、CI runner、notebook、sandbox
fixed kernelで再起動済みか	ベンダーadvisoryと起動中kernel	kernel更新済みでも未再起動なら未完了

kernel更新では、パッケージを入れただけでは不十分です。多くの環境では、修正版kernelで再起動して初めて対応が有効になります。

P1はKubernetes、CI、sandbox、共有ホスト¶

優先度が最も高いのは、低権限コード実行が通常運用に含まれるホストです。

Copy Failは、低権限ローカルユーザーがpage cacheに対して制御された4バイト書き込みを行い、setuid binaryのような対象を使ってroot権限取得につなげると説明されています². Xintは、ディスク上のファイルではなくpage cache上の内容が改変される点も強調しています².

優先度	環境	理由
P1	Kubernetes node / container host	Podやコンテナはホストkernelを共有する
P1	self-hosted CI runner / Jenkins agent	PRやビルドスクリプトが任意コード実行の入口になる
P1	notebook / AI sandbox	利用者コードを実行するため、multi-tenant環境で危険度が上がる
P1	共有開発サーバ / 踏み台サーバ	一般ユーザーや侵害済み認証情報からroot化され得る
P2	Web / app / build server	別のRCEや認証情報漏えいと組み合わさると危険
P3	管理者のみの内部VM / 単一ユーザー検証VM	ローカル攻撃の前提が満たされにくい

copy.failの公開情報では、untrusted workloadsではpatch stateにかかわらずAF_ALG socket creationをseccompでブロックすることが推奨されています¹. ここでいうuntrusted workloadsには、containers、sandboxes、CIが含まれます。

2026年4月30日時点の公開ステータス¶

ベンダーの状態は変わります。ここでは、2026年4月30日に確認できた公開情報だけを扱います。

NVDのCVE説明では、問題はLinux kernelの crypto: algif_aead にあります。修正は、algif_aead のin-place operationを取りやめる内容です³.

oss-securityの投稿では、問題はLinux 4.14のcommit 72548b093ee3 で導入されたとされています。同投稿では、6.18.22、6.19.12、7.0で修正commitが示されています⁴.

情報源	2026-04-30時点の要点
Linux kernel / oss-security	4.14で導入、6.18.22 / 6.19.12 / 7.0で修正commitあり
Ubuntu	PriorityはHigh、理由は “Trivial local privilege escalation”、CVSS 7.8 High⁶
Debian	bullseye / bookworm / trixie系はvulnerable、forky / sidはfixed表示⁷
Amazon Linux	Amazon Linux 2 / 2023の複数kernel packageがPending Fix表示⁸
SUSE / openSUSE	SLES 15 SP7、SLES 16.0、SUSE Linux Micro 6.x、openSUSE Leap 15.6など多数がAffected表示⁹

Xint / Theoriは、Ubuntu 24.04 LTS、Amazon Linux 2023、RHEL 10.1、SUSE 16の組み合わせで検証したと説明しています¹². 同じPoCでroot取得できることを確認した、という位置づけです。これは研究者による検証情報であり、ベンダーの正式なfixed判定とは分けて扱うべきです。

対応は更新、再起動、暫定制限の順で考える¶

恒久対応は、利用中のディストリビューションが提供する修正版kernelへ更新し、そのkernelで再起動することです。

Debian / Ubuntu系では、起動中kernelとインストール済みkernelを見ます。

uname -r
dpkg -l | grep linux-image

RHEL / Amazon Linux / SUSE系では、RPM packageと起動中kernelを見ます。

rpm -q kernel
uname -r

すぐにkernel更新や再起動ができない場合は、暫定策として algif_aead moduleの無効化を検討します。oss-securityでもmitigationとして同様の方法が示されています⁴.

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead 2>/dev/null || true

この方法は万能ではありません。kernelに組み込み済みの場合はmoduleとして外せず、既に利用中なら rmmod できないことがあります。

untrusted workloadを動かす基盤では、修正版kernelへの更新に加えて、AF_ALG socket creationの制限を検討します。 copy.failは、containers、sandboxes、CIではpatch stateにかかわらずseccompでAF_ALGをブロックすることを推奨しています¹.

AIは何をしたのか¶

Copy Failのニュース性は、脆弱性の内容だけではありません。発見プロセスにAIが関与した点も重要です。

copy.failの公式ページでは、Copy FailはXint CodeによってLinux crypto/ subsystemの約1時間のスキャンから surfaced されたと説明されています¹. Xintの記事では、研究者が splice() とpage-cache referencesに関する観察をoperator promptに含めた、とされています². read-only fileやsetuid binaryのpage cacheが、crypto TX scatterlistsへ届き得るという観察です。

この説明から見ると、「AIが完全自律でゼロデイを見つけた」と言い切るのは粗いです。一方で、「AIはおまけだった」と見るのも弱すぎます。

より正確には、人間研究者の攻撃面理解を起点に、AIがLinux kernel内の複雑なコード経路を横断探索し、高重大度の脆弱性候補を浮上させた事例 と見るべきです。

BugcrowdのDavid Brumley氏も、この点を「The bug matters. The way it was found matters more.」と表現しています。 AI systemが約1時間でこの種のLinux LPEを浮上させた点を重く見ています⁵.

Criticalではないが、軽くもない¶

CVE-2026-31431は、典型的なCritical RCEではありません。攻撃元はLocalで、低権限のコード実行が必要で、このCVE単体でネットワーク越しに侵入できるものではありません。

それでも、Kubernetes node、CI runner、sandbox、notebook、共有サーバでは話が変わります。これらの環境では、低権限コード実行が例外ではなく、通常運用の一部だからです。

リスク = 脆弱kernelの有無 × 低権限コード実行の起こりやすさ × ホスト侵害時の影響範囲

この式で見ると、同じCVEでも優先度は変わります。DB専用VMより、PRコードを実行するself-hosted runnerのほうが先に確認すべきです。

これから必要になるのは即時判定できる資産管理¶

今回の問題は、Linux kernelの脆弱性対応であると同時に、AI時代の脆弱性運用の問題でもあります。

AIが脆弱性探索の速度と範囲を押し広げるなら、運用側も影響範囲を機械的に切れる必要があります。必要なのは、ホスト一覧、起動中kernel、OSディストリビューション、Kubernetes nodeかどうか、CI runnerかどうか、共有ログインの有無、fixed kernelで再起動済みか、という情報です。

これらが分散していると、CVEの深刻度より先に棚卸しで時間を失います。

Copy Failへの対応で最初にやることは、Linuxホストを洗い出し、低権限コード実行が起こり得るホストを優先することです。その上で、ベンダーのCVEページでfixed / vulnerableを確認し、修正版kernelへ更新し、fixed kernelで再起動します。

すぐ更新できない場合は algif_aead 無効化を検討し、CI / Kubernetes / sandboxではAF_ALG制限も検討します。 AIが発見を速くするなら、守る側も「どこが影響を受けるか」を速く判断できる設計が必要です。

まとめ¶

CVE-2026-31431 “Copy Fail” は、HighのLinux kernelローカル権限昇格脆弱性です。 Critical RCEではありませんが、Kubernetes node、CI runner、sandbox、共有ホストでは優先度が高くなります。

対応の軸は、対象Linuxホストの棚卸し、ベンダーadvisoryの確認、修正版kernelへの更新、fixed kernelでの再起動です。更新がすぐ難しい環境では、algif_aead 無効化やAF_ALG制限を暫定策として検討します。