セキュリティ専門メディアArs Technicaが2026年5月11日に報じたところによると、Linuxに「Dirty Frag」と呼ばれる深刻な権限昇格脆弱性が発覚した。1週間前に明らかになった「Copy Fail」に続く2週連続の深刻な脅威であり、すでにPoC（概念実証）コードが公開され、Microsoftも実環境での悪用の兆候を確認・公表している。

本記事では、Ars Technicaの報道に加え、Wizが公開した詳細な技術分析レポートの情報も統合し、具体的な対策手順までカバーする。

なぜ「Dirty Frag」が危険なのか

Dirty Fragは、CVE-2026-43284とCVE-2026-43500の2つの脆弱性を連鎖させる攻撃手法だ。低権限ユーザーがLinuxカーネルのpage cache処理の不備を突くことで、root権限を取得できる。クラウドや共有ホスティング、コンテナ環境のようなマルチテナント構成での悪用が特に危険とされる。

特に深刻なのは、このエクスプロイトが「決定論的（deterministic）」である点だ。レースコンディションに依存する従来のカーネルエクスプロイトとは異なり、ほぼすべてのLinuxディストリビューションで同一の挙動を示し、かつシステムクラッシュを引き起こさない。Ars Technicaによると、セキュリティ企業Automoxはこの特性を「実行が極めてステルシー」と評価している。

技術的な仕組み——Dirty Pipeと同じ系譜

Automoxの研究者らは次のように解説している。Dirty Fragはカーネルのstruct sk_buff構造体のfragメンバーを標的とし、splice()システムコールを使って読み取り専用のpage cacheページ（/etc/passwdや/usr/bin/suなど）への参照を埋め込む。その後、受信側のカーネルコードが暗号化処理をそのページ上で直接実行することでpage cacheが改ざんされ、攻撃者は読み取り権限しか持っていないにもかかわらず、以降のファイル読み取りが汚染されたデータを返す状態になる。

2つのCVEの内訳

Wizの詳細分析によれば、2つのCVEはそれぞれ異なるカーネルサブシステムに存在する。

CVE対象サブシステム脆弱性が存在する期間
CVE-2026-43284xfrm-ESP（IPsec）— esp4/esp62017年頃から（約9年間）
CVE-2026-43500RxRPC2023年頃から（約3年間）

ESPサブシステムの脆弱性は約9年間もカーネルに潜伏していたことになる。これは2022年のDirty Pipe、そして直近のCopy Fail（CVE-2026-31431）と同じバグファミリーに属する脆弱性であり、Wizはこれを「CopyFail2」とも呼んでいる。

悪用に必要な条件

Wizのレポートでは、悪用に必要な条件として以下を挙げている。

  • 脆弱なカーネルインターフェースへのローカルアクセス
  • splice()関連パスを通じたpage-backedバッファの操作
  • 通常はCAP_NET_ADMINケーパビリティが必要

ただし注意が必要なのは、デフォルトのseccompプロファイルが適用されたKubernetes環境では悪用が困難とされる一方、VMや制限の緩いコンテナ環境ではリスクが高いという点だ。PoCはfixコミットのリバースエンジニアリングから作成されており、攻撃の再現性は高い。

影響を受けるディストリビューション

Wizの調査に基づく影響範囲は以下の通り。主要ディストリビューションのほぼすべてが影響を受ける。

ディストリビューション影響状況
Ubuntu（複数バージョン）⚠️ 影響あり（検証済み）
RHEL 8 / 9 / 10⚠️ 影響あり
CentOS Stream 10⚠️ 影響あり
AlmaLinux 8 / 9 / 10✅ パッチ提供済み
Fedora（最近のバージョン）✅ パッチ提供済み
Debian✅ パッチ提供済み
openSUSE Tumbleweed⚠️ 影響あり
OpenShift 4⚠️ 潜在的に影響あり

海外セキュリティ企業の評価

Aviatrixの研究者らはArs Technicaの報道の中で、「Dirty Fragはパッチ未適用のカーネル上で認証なしにroot権限を取得できる、即時かつ重大な脅威だ」と評価。PoCが公開されており、限定的とはいえ実環境での悪用も観測されているとして、迅速なパッチ適用と緩和策の実施を強く促している。

Microsoftも、ハッカーがDirty Fragを実験的に悪用している兆候を確認したと発表した。

開示の経緯

発見者の研究者Hyunwoo Kim氏（@v4bel）が2026年5月8日に脆弱性を開示した直後、エンバーゴ期限前に第三者がfixコミットからリバースエンジニアリングで詳細を特定。Kim氏はゼロデイ化を受ける形でPoC（概念実証）のソースコードをGitHub上で公開した。Linuxカーネル本体にはパッチが取り込まれているものの、多くのディストリビューションではまだパッチが行き渡っていない状況にある。

今すぐやるべきこと——具体的な対策ガイド

Wizのレポートと各ベンダーのアドバイザリをもとに、対策を優先度順に整理した。

1. カーネルパッチの適用（最優先）

パッチが提供されているディストリビューション（Debian・AlmaLinux・Fedora）を使っている場合は、即座にカーネルを更新する。

# Debian/Ubuntu系
sudo apt update && sudo apt upgrade linux-image-$(uname -r) -y && sudo reboot

# RHEL/AlmaLinux/CentOS系
sudo dnf update kernel -y && sudo reboot

# Fedora
sudo dnf update kernel -y && sudo reboot

RHEL・Ubuntu・SUSE等でまだパッチが出ていない場合は、下記の暫定緩和策を実施する。

2. 暫定緩和策——脆弱なカーネルモジュールの無効化

パッチ適用までの間、脆弱なモジュールのロードを禁止することで攻撃面を縮小できる。

# esp4, esp6, rxrpcモジュールの無効化
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
  > /etc/modprobe.d/dirtyfrag.conf"

# すでにロードされている場合はアンロード
sudo rmmod esp4 esp6 rxrpc 2>/dev/null; true

⚠️ 業務影響の確認が必須:

  • esp4/esp6を無効化するとIPsec VPN通信が不可になる。VPN接続を使っている場合は代替手段を確保してから実施すること
  • rxrpcを無効化するとAFS（Andrew File System）が使用不可になる。AFS環境は国内では少数だが、該当する場合は注意が必要

3. アクセス制御の強化

悪用にはCAP_NET_ADMINケーパビリティとローカルアクセスが必要となるため、以下の対策が有効だ。

  • シェルアクセスの制限: 不要なユーザーのシェルアクセスを見直す
  • MAC（強制アクセス制御）の適用: SELinuxやAppArmorをenforcingモードで運用する
  • ケーパビリティの最小化: コンテナやサービスに対して不要なCAP_NET_ADMINを付与しない
  • Kubernetes環境: デフォルトのseccompプロファイルが適用されていることを確認する

4. 侵害検知——何を監視すべきか

すでに悪用されている可能性を考慮し、以下の兆候を監視する。

  • 異常な権限昇格の検出: 予期しないuidの変更やsudo/su以外のroot昇格
  • コンパイルツールの実行: gccやmakeがサーバー上で実行されていないか（エクスプロイトのコンパイル痕跡）
  • 重要バイナリの整合性チェック: /etc/passwd、/usr/bin/suなどpage cache汚染の対象となりうるファイルのハッシュを確認
  • カーネルモジュールの状態: esp4、esp6、rxrpcモジュールが予期せずロードされていないか

5. 侵害後のpage cacheクリーンアップ

万が一侵害が疑われる場合、page cacheを強制的にドロップすることで、汚染されたキャッシュデータをクリアできる。

# page cacheの強制ドロップ（本番環境では一時的な性能低下に注意）
echo 3 | sudo tee /proc/sys/vm/drop_caches

これは根本対策ではなく応急処置である。侵害が確認された場合は、完全なインシデントレスポンス（フォレンジック調査・影響範囲の特定・カーネル更新後の再起動）が必要だ。

日本市場での注目点

国内でもLinuxサーバーを運用する企業・クラウド事業者は多く、特にVPS・コンテナ・共有ホスティングなどのマルチテナント環境を提供している場合は対応優先度を最高に設定すべき状況だ。

Azure上でLinux VMを運用している場合は、MicrosoftがDirty Fragの悪用兆候を公表している経緯もあり、Microsoft Security Response Center（MSRC）の情報も合わせて追っておくとよい。AWSもセキュリティブリテン（2026-027-aws）を公開しており、主要クラウドベンダーが一斉に対応に動いている。

筆者の見解

2週間で2本の深刻なroot権限昇格脆弱性が立て続けに発覚したことは、Linuxカーネルのpage cache実装における設計上の課題を改めて浮き彫りにしている。Dirty Pipe（2022年）、Copy Fail、そしてDirty Fragと、同一系譜の脆弱性が繰り返し現れている以上、単なる「運の悪い一致」では済まないだろう。

特に今回注目すべきは、ESPサブシステムの脆弱性が約9年間もカーネルに潜伏していた点だ。カーネルのsplice()とpage cacheの境界における書き込み制御は構造的な弱点となっており、今後も同種の脆弱性が発見される可能性を念頭に置くべきだ。

「PoC公開＝即時脅威」という状況が常態化しつつある今、定期メンテナンスウィンドウを待つ従来の運用フローでは対応が間に合わない。パッチ管理の自動化と適用スピードの向上が、インフラ運用の競争力を左右する時代に入っていると改めて感じさせられる事例だ。自動パッチ適用の仕組みをまだ持っていない組織にとっては、今回の一件を見直しの契機にしてほしい。

参考リンク

出典: この記事は Linux bitten by second severe vulnerability in as many weeks（Ars Technica） および Dirty Frag: Linux Kernel Local Privilege Escalation（Wiz） の内容をもとに、筆者の見解を加えて独自に執筆したものです。