Summary

Linuxカーネルの権限昇格脆弱性「Copy Fail(CVE-2026-31431)」とDirty Fragを解説。Docker・Kubernetesへの影響や、algif_aead無効化・seccompによる暫定対策について整理します。

概要

2026年4月末、Linux カーネルに対する深刻なローカル権限昇格(LPE: Local Privilege Escalation)脆弱性:

  • Copy Fail(CVE-2026-31431)

が公開されました。

IPAの情報
Linuxの脆弱性対策について(CVE-2026-31431、Copy Fail)

さらにその直後、同系統の攻撃手法:

  • Dirty Frag

も登場し、Linux コミュニティやクラウド事業者に大きな衝撃を与えています。

ローカル権限昇格のため、RCE(リモートコード実行)ほど優先度が高くスルーされることが多いのですが、

今回特に問題視されているのは:

  • exploit が非常に簡単(ファイルを作成する必要なし。単体で攻撃成功)
  • Kubernetes / Docker に影響
  • OpenSSL にも関連
  • patch前提でも多層防御が必要

という、暗号を扱う箇所の脆弱性のため「インフラ全体」の問題になっています。

また、

  • race condition 不要
  • exploit が小さい
  • 成功率が高い
  • ディストリビューション差異が少ない(Kernelが対象のため)
  • exploit code 公開済み

という特徴があります。

※2026年5月8日時点では、Copy Failのパッチは提供されていますが、Dirty Fragのパッチは提供されていません。

Copy Fail(CVE-2026-31431)とは

Copy Fail は Linux kernel の暗号サブシステムに存在するローカル権限昇格脆弱性です。

影響範囲は非常に広く:

Linux Kernel 4.14 以降
が対象とされています。

つまり:

2017年以降のほぼ全Linux
です。

Red Hat の公開情報では:

  • RHEL 8
  • RHEL 9
  • RHEL 10

が影響対象です。(RHEL7は影響対象外)

問題の中心は AF_ALG:暗号処理用ソケット

難しいことは省略しますが、今回の問題は、AF_ALGという Kernel Crypto API を userspace から利用する socket インターフェースです。

Kernel Crypto APIは、OpenSSLやSSH、dm-crypt、Kernel TLS、IPsec/XFRMなどで利用できますが、
通常は、これらはAF_ALGを経由せずに、Kernel Crypto APIを直接利用しています。
※Configで明示的にAF_ALGを有効化している場合は除く

暫定対策

恒久対策は、パッチの適用ですが、暫定対策もご紹介します。
※Dirty Fragの暫定対策にはなりません。

現在、各ベンダ・CSIRT・研究者が推奨している暫定対策は主に2つです。

1. algif_aead モジュール無効化

最も一般的な暫定対策 です。

例:

# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf

# rmmod algif_aead
 

ただし、RHEL系やWSL2では、algif_aead が built-in の場合があり、無効化できない場合があります。

2. seccomp で AF_ALG をブロック

seccomp(Secure Computing mode)は、Linuxカーネルが提供するセキュリティ機能で、プロセスがカーネルに対して発行できるシステムコールを制限し、不正な操作や脆弱性を悪用した攻撃からシステムを守るサンドボックス技術です。

exploit開始時に AF_ALGソケットが必要な攻撃であるため、AF_ALGを禁止してしまえばいいという考え方です。
Kernel Crypto APIをAF_ALGを経由せずに直接利用するアプリが一般的なので、影響はほぼ無いと考えています。
※ 念のため、lsof や ss -za などで AF_ALGソケットを確認してください。

特に:

  • Kubernetes
  • Docker
  • CI/CD runner
  • SaaS multi-tenant
  • sandbox

では重要です。

まとめ

今回:

  • Dirty Pipe
  • Copy Fail
  • Dirty Frag

と続いたことで、
AF_ALG を 信頼できないworkload に不要なら閉じるべき という考え方が強くなっています。
つまり、patchだけではなく attack surface 自体を減らす方向です。

コンテナ運用者は実施しているかもしれませんが、
今後は「patch管理」+「attack surface削減」+「untrusted workload隔離」
が、Linux セキュリティの重要テーマになっていくかもしれません。

追記)
上記の対応方法では、Dirty Fragの暫定対応にはなりません。Patchを待ちましょう
(splice 由来の page cache page が skb frag に入り、 xfrm-ESP の in-place crypto がそれを書き換えるような動作のため)
(Dirty Pipeがstruct pipe_bufferを上書きするのに対し、Dirty Fragは struct sk_buff のFragを上書きします)

著者紹介
山田幸志
山田幸志

MS365認定アドミニストレーターエキスパート、情報処理安全確保支援士。
Microsoft 365を中心としたクラウド、セキュリティ、インフラ領域を専門とするITエンジニア。
でも得意分野はLinux/仮想化。

日本最古のITコミュニティの幹事や、日本最大のネットワークオペレーター会議の実行委員長、セキュリティイベントやGadgetイベント発起人など、数多くの技術コミュニティの運営に携わる。コミュニティ活動を通じて幅広い知見と実践的なスキルを磨き、現場で得た経験や技術情報を発信している。

関連投稿

AI
MS365 CopilotのWork IQ

Microsoft 365 Copilotの新機能「Work IQ」を解説。組織内のメールや会議記録、SharePoint情報を活用した業務支援の仕組みを紹介します。

Read More

お問い合わせ