Dirty Frag（CVE-2026-43284）解説：Linuxカーネル特権昇格の仕組みと全ディストリで有効な防御策

2026年5月7日、研究者Hyunwoo Kimが「Dirty Frag」と名付けたLinuxカーネルのローカル特権昇格（LPE）脆弱性を公開した。CVE-2026-43284（IPsec ESP、CVSS 8.8）とCVE-2026-43500（RxRPC、CVSS 7.8）という2つのページキャッシュ書き込みバグをチェーンし、非特権ユーザーが1コマンドでroot権限を取得できる。Copy Fail（CVE-2026-31431）に続く「Linuxカーネルを襲った第2の主要バグ」（The Record Media）と位置づけられており、タイミング依存の競合を一切持たない決定論的なロジックバグとして設計されている。エンブレゴ（embargo）が第三者によって破棄されたため、パッチが存在しない状態でPoC（概念実証コード）が公開されるという異例の経緯を辿り、翌5月8日にはMicrosoftが実際の攻撃キャンペーンを確認・記録した。

Linuxカーネルセキュリティ全般の攻撃手法と防御フレームワークを体系的に理解したい場合は、サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストも合わせて参照してほしい。

Dirty Fragとは—Linuxカーネル全ディストリに影響する特権昇格脆弱性の概要

Dirty Fragという名称は、Linuxカーネルのネットワーク層が管理するソケットバッファ（sk_buff）の「frag」メンバに由来する。2022年のDirty Pipe、2026年4月のCopy Fail（CVE-2026-31431）と同様、読み取り専用のページキャッシュに対して非特権ユーザーが書き込みを行えてしまうという脆弱性クラスの延長線上に位置する。Copy Failから1か月も経たずに公開されたことから、The Record Mediaをはじめとする複数のメディアが「Linuxカーネルを襲った第2の主要バグ」と報じた。

Hyunwoo Kimはこの脆弱性について「タイミングウィンドウに依存しない決定論的なロジックバグであり、失敗してもカーネルパニックを引き起こさない」と説明している。従来の競合状態（race condition）を利用するLPEとは根本的に性質が異なり、成功率が事実上100%に近い点が防御側にとって特に深刻だ。

発見の背景として、Hyunwoo Kimは同系統のバグ「Copy Fail」の研究を通じてページキャッシュ書き込みという脆弱性クラスを深く理解し、同様の不備がESPとRxRPCにも存在することを突き止めた。研究者自身がPublic Disclosureの文書内で「Copy Failとの関係」を明示しており、同一ルートコーズに基づく異なる経路の発現と位置付けられる。

GitHubリポジトリ V4bel/dirtyfrag は公開直後から急速にスターを集め、セキュリティコミュニティの注目度の高さを示している。リポジトリにはポイントリリースごとの動作確認済みカーネルバージョンと、モジュールブラックリストによる即時ミティゲーションスクリプトが含まれている。

ページキャッシュとsk_buffフラグメント—脆弱性が生まれる技術的背景

Dirty Fragを理解するには、LinuxカーネルにおけるページキャッシュとゼロコピーI/Oの仕組みを把握する必要がある。

Linuxページキャッシュの基本構造

Linuxカーネルはディスクから読み込んだファイルデータをメモリ上のページキャッシュ（Page Cache）に保持し、複数プロセスから共有参照できるようにする。/etc/passwdや/usr/bin/suなどのシステムファイルは、読み取り専用であっても常にページキャッシュを通じてアクセスされる。

通常の書き込み操作では、カーネルはコピーオンライト（COW: Copy-on-Write）の原則に従い、共有ページへの変更前に必ずプライベートコピーを作成する。この仕組みにより、あるプロセスがファイル内容を変更しても他プロセスへの影響を防いでいる。

ゼロコピーI/Oとspliceが生み出す攻撃面

splice(2)やsendfile(2)、MSG_SPLICE_PAGESフラグを使うと、ユーザー空間を経由せずにカーネル内でデータを転送できる（ゼロコピー転送）。この仕組みでは、送信側がページキャッシュページへの参照（pinned reference）をsk_buffのfragスロットに直接渡す。送信側プロセスが依然としてそのページへの参照を保持したまま、ページがネットワークスタックに渡される。

Dirty Fragではこのゼロコピーの仕組みを悪用する。攻撃者は標的ファイル（/usr/bin/suなど）を読み取り専用でオープンし、spliceを使ってそのページキャッシュ参照をESP/RxRPCソケットのsk_buffフラグメントに植え付ける。その後、インプレース復号処理が発動すると、カーネルはCOWチェックを経ずにそのページに直接書き込んでしまう。

重要な点として、この書き込みはメモリ上のページキャッシュにのみ適用され、ディスク上の元のファイルは変更されない。そのため、ファイルの整合性をディスクで確認する従来のFIM（File Integrity Monitoring）ツールでは検出が困難であり、攻撃者にとって有利な特性となっている。

sk_buffのfragスロットと問題の核心

Linuxカーネルのsk_buff（ソケットバッファ）構造体は、分散・収集I/O用に複数の「フラグメント（frag）」を保持できる。送信側がspliceでページキャッシュページをsk_buffのfragスロットに連結した場合、そのページはカーネルが「所有」しているわけでなく、ユーザープロセスが依然として参照権を持つ外部バックドページとなる。

Dirty Fragの核心は、ESP（IPsec暗号化）やRxRPC（Kerberosベース認証プロトコル）の受信パスが、このfragスロット内の外部バックドページに対して直接インプレース復号を行ってしまう点にある。通常はskb_cow_data()という関数がCOWチェックを行いプライベートコピーを作成するはずだが、特定の条件下でこのチェックが完全にスキップされる。

2つのCVEチェーンの仕組み—ESP4/ESP6とRxRPCの動作原理

Dirty Fragは2つの独立したCVEを使い分けることで、主要なLinuxディストリビューションを網羅する設計になっている。どちらも「ページキャッシュへの不正書き込み」という原始的能力（プリミティブ）を提供するが、必要な権限と依存モジュールが異なる。

CVE-2026-43284（CVSS 8.8）：xfrm-ESP Page-Cache Write

xfrm（IPsec変換）フレームワークのesp4・esp6モジュールに存在する脆弱性だ（CVSS v3.1スコア: 8.8）。ESPの受信パスで非線形sk_buff（paged fragを含むもの）に対してインプレース復号を行う際、skb_cow_data()のCOWチェックが特定の条件下でバイパスされる。その結果、攻撃者が制御するfragページ上に直接復号結果が書き込まれる。

この経路を使うには名前空間（namespace）作成権限が必要だが、多くのディストリビューションではデフォルトで非特権ユーザーが名前空間を作成できるよう設定されている。ただし、AppArmor等で厳格に制限しているディストリビューションでは単独では利用できない。

• 脆弱性コミット: cac2661c53f3（2017年1月17日）以降のすべてのカーネル
• パッチコミット: f4c50a4034e6（SKBFL_SHARED_FRAGフラグによる共有frag検出）
• パッチ状況: 2026年5月8日に主要ディストリで提供開始

CVE-2026-43500（CVSS 7.8）：RxRPC Page-Cache Write

RxRPCサブシステムのrxkad_verify_packet_1()関数に存在する脆弱性だ（CVSS v3.1スコア: 7.8）。Kerberosベースの認証プロトコルRxRPCの検証パスで、pcbc(fcrypt)アルゴリズムによる8バイトのインプレース復号がsplice固定ページに直接適用される。

この経路は名前空間作成権限を必要としない点が大きな特徴だ。ただしrxrpc.koモジュールがロードされている必要があり、主にUbuntuで標準搭載されている（多くのRHEL系ディストリはデフォルトでrxrpcを持たない）。

• 脆弱性コミット: 2dc334f1a63a（2023年6月）以降のカーネル
• パッチ状況: 2026年5月11日時点で未提供（モジュールブラックリストのみ）

チェーン戦略：2つの経路で全ディストリをカバー

影響範囲—Linuxカーネルバージョンと確認済みディストリビューション

Dirty Fragの影響範囲は非常に広い。xfrm-ESP側は2017年から約9年にわたって潜在していたバグであり、RxRPC側は2023年6月以降の約3年間が対象となる。

確認済み影響ディストリビューションとパッチ状況（2026年5月11日）

Canonicalは公式ブログで「Trusty Tahr（14.04 LTS）からResolute Raccoon（26.04 LTS）まで、すべてのUbuntuリリースが影響を受ける」と明示しており、対応するUSNが発行されている。

クラウド環境への影響

AWS・GCP・Azureなどのクラウド環境でもLinuxベースのインスタンスはすべて影響を受ける可能性がある。特に多テナント環境（複数ユーザーが同一ホスト上で動く場合）では、ホストカーネルへのLPEがコンテナブレイクアウトに直結するリスクがある。

Wiz Blogの分析では、「Kubernetesのデフォルトseccompプロファイルを持つハードニングされたコンテナ環境ではリスクが低減される」と指摘している。ただし、仮想マシンや--privilegedコンテナ、アクセス制限が緩い環境では重大なリスクが残存する。

AWS公式のセキュリティアドバイザリ（AWS-2026-027）では、Amazon Linux 2023向けの対応状況と暫定ミティゲーション手順が公開されている。マネージドKubernetesサービス（GKE・AKS・EKS）のコントロールプレーンへのパッチ適用は各クラウドプロバイダーが自動実施している。

Androidへの影響

AndroidはLinuxカーネルをベースとするが、Dirty Fragの主要な経路については以下の理由から標準的なAndroid端末での悪用は限定的だ。

・標準AOSPはrxrpc.koを含まないため、CVE-2026-43500の経路は適用されない。
・Androidのカーネルはネットワーク構成が一般的なサーバーLinuxと大きく異なり、IPsec ESPの利用形態も制限されている。
・ただし、カスタムカーネルを搭載したAndroid派生OS（カスタムROM等）や、ルート化されたデバイスでは影響を受ける可能性がある。

Googleは2026年5月のAndroidセキュリティ情報にてESP関連のカーネルパッチの適用計画を含めることを発表した。Pixelデバイスは2026年6月のセキュリティアップデートにてパッチが適用される見通しだ。

野生での悪用確認—Microsoftが記録した攻撃チェーン

Dirty Fragの公開翌日となる2026年5月8日、MicrosoftのセキュリティブログがDirty FragまたはCopy Fail技術と整合する「限定的な野生での活動（limited in-the-wild activity）」を記録・公開した。これは本脆弱性の深刻さを裏付けるとともに、防御側が暫定ミティゲーションを急ぐ必要性を改めて示している。

Microsoftが記録した攻撃シーケンス

Microsoftが観測した攻撃は以下の手順で進行した。

攻撃の各ステップを詳しく見てみよう。

Step 1: 初期アクセス — 攻撃者は外部からSSH接続でLinuxサーバーに侵入し、インタラクティブシェルを確立した。初期アクセスは非特権ユーザー権限でのログインだ。このステップ自体はDirty Fragとは無関係で、フィッシングや認証情報窃取で成立したと推測される。

Step 2: 特権昇格 — ./updateという名称のELFバイナリを実行することでDirty Fragエクスプロイトが発動し、suコマンド経由でroot権限を取得した。Dirty Fragの典型的な悪用では、/usr/bin/suのメモリ上の内容（最初の192バイト）を改ざんした悪意あるELFコードで置き換え、su実行時にroot権限でシェルを起動させる。

Step 3: 横展開と改ざん — root権限取得後、攻撃者はGLPI（ITアセット管理ツール）のLDAP認証設定ファイルを改ざんした。これにより認証バイパスや内部ネットワークへの横展開が可能になる。

Step 4: 情報収集と痕跡隠滅 — システムの偵察を実行した後、攻撃者は残留するセッションファイルを読み取り、その後強制的に上書き・削除した。これは発見を困難にするためのアンチフォレンジック行為だ。

検出の困難さとIOC

Dirty Fragの攻撃が特に厄介な点は、ファイル改ざんがメモリ上のページキャッシュにのみ適用され、ディスク上の実体は変更されないことだ。そのため、ファイルハッシュの整合性チェックやFIMツールでは検出できない。防御チームが参照すべき指標（IOC候補）は以下のとおりだ。

・suコマンドへの異常なアクセスパターン（通常使わないユーザーがsuを実行）。
・dmesgや/var/log/kern.logでのモジュールロード/アンロードの記録。
・./updateなど不審な名称のELFバイナリの実行ログ（auditdで捕捉可能）。
・GLPI等のアプリケーション設定ファイルへの予期しない変更（ディスク上の変更として現れる場合）。
・非特権ユーザーによるmodinfo・lsmodコマンドの実行（情報収集フェーズ）。

Dirty Pipeファミリーの系譜—Copy FailからDirty Fragへの変遷

Dirty Fragは2022年のDirty Pipe発見以来続く、Linuxカーネルの「ページキャッシュ書き込み」脆弱性クラスの最新版と言える。Hyunwoo Kim本人も公開文書内でこの系譜を明示している。The Record Mediaはこの文脈からDirty Fragを「Linuxカーネルを襲った第2の主要バグ」と報じており、業界全体で「1か月間に2つのページキャッシュ書き込みLPEが登場した」という重大性を強調している。

ページキャッシュ書き込みバグクラスの変遷

技術的な差異：3世代の比較

Dirty Fragが過去2つのバグと最も異なる点は、「embargo破棄」という前代未聞の経緯でパッチ未適用のまま公開され、しかも公開翌日には野生での悪用が確認されたという点だ。通常のresponsible disclosureでは開示前にパッチが用意されるが、Dirty Fragでは第三者が独立して脆弱性を発見・公開したため、カーネル開発者がパッチを準備する前にPoCが出回ることになった。

Copy Fail（CVE-2026-31431）との関係については、当サイトの解説記事「Copy Fail（CVE-2026-31431）解説：Linuxカーネル脆弱性とEC2/ECS/EKSへの影響」で詳しく取り上げているので参照してほしい。

即時ミティゲーションと防御策—今すぐ実行できる対処法

Dirty Fragに対して現時点で取れる防御策は、脆弱なカーネルモジュールの無効化とカーネルパッチの適用の2軸だ。CVE-2026-43284については主要ディストリでパッチが提供されているため、可能であればパッチ適用を優先すること。

Step 1：脆弱モジュールのブラックリスト登録（即時適用可）

最も迅速に実施できるミティゲーションはモジュールのブラックリスト登録だ。以下の設定ファイルを作成し、再起動後にモジュールがロードされないようにする。

# /etc/modprobe.d/dirtyfrag.conf を作成
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
  | sudo tee /etc/modprobe.d/dirtyfrag.conf

Ubuntu環境では、initramfsの再生成も必要だ。

# Ubuntu: initramfsを再生成してブラックリストを有効化
sudo update-initramfs -u -k all

既にモジュールがロード済みの場合は、以下で即時アンロードを試みる。

# 現在ロード済みかどうかを確認
lsmod | grep -E "^(esp4|esp6|rxrpc)"

# ロードされていた場合は除去（使用中プロセスがある場合は失敗することがある）
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true

# ページキャッシュのクリア（汚染済みの場合の後処理）
echo 3 | sudo tee /proc/sys/vm/drop_caches

Step 2：モジュールのロード状況確認スクリプト

以下のスクリプトで、対象モジュールのロード状況を確認できる。インフラ自動化ツール（Ansible・Chef等）から実行してシステム全体の状況を把握するのに使える。

#!/bin/bash
# check_dirtyfrag.sh — Dirty Frag影響確認スクリプト（防御用）
echo "=== Dirty Frag (CVE-2026-43284/43500) モジュール確認 ==="
echo "カーネルバージョン: $(uname -r)"

for mod in esp4 esp6 rxrpc; do
  if lsmod | grep -q "^${mod}"; then
    echo "[警告] ${mod}: ロード済み — ブラックリスト登録を推奨"
  elif modinfo "${mod}" &>/dev/null; then
    echo "[注意] ${mod}: 利用可能（未ロード） — ブラックリスト登録を推奨"
  else
    echo "[OK]  ${mod}: システムに存在しない"
  fi
done

echo ""
echo "ブラックリスト設定の確認:"
cat /etc/modprobe.d/dirtyfrag.conf 2>/dev/null || echo "  ミティゲーション未適用"

Step 3：カーネルパッチの適用（正式対処）

xfrm-ESP側（CVE-2026-43284）のパッチは2026年5月7日にnetdevツリーにマージされ、翌5月8日には主要ディストリビューションでパッケージ提供が始まった。修正の核心はSKBFL_SHARED_FRAGフラグの導入だ。splice固定のページキャッシュページを含むsk_buffにこのフラグをセットし、受信パスで確実にskb_cow_data()が呼ばれるようにする。

各ディストリビューションのパッチ対応状況（2026年5月11日現在）:

パッチを適用した後は、モジュールブラックリスト設定を削除してIPsec機能を復元できる。

# パッチ適用後にミティゲーションを解除する場合
sudo rm /etc/modprobe.d/dirtyfrag.conf
sudo update-initramfs -u -k all  # Ubuntu の場合
sudo reboot

AppArmorによる補完的防御

Ubuntu環境では、AppArmorプロファイルで名前空間作成を制限することでxfrm-ESP経路の緩和策となる。ただしRxRPC経路には効果がないため、モジュールブラックリストと組み合わせることが重要だ。

# Ubuntu: ユーザー名前空間の制限設定（補完的対策）
# kernel.unprivileged_userns_clone=0 は副作用が大きいため慎重に適用すること
sysctl -n kernel.unprivileged_userns_clone

脆弱性管理の体系的なアプローチについては、Faraday徹底解説：6.5kスターの脆弱性管理プラットフォームOSS、80+セキュリティツール統合も参考になる。

カーネルkillswitch提案—Sasha Levinが示す緊急緩和策の新たな形

Dirty FragとCopy Failが相次いで公開された翌日の2026年5月7日、Linux安定カーネル共同メンテナ兼NVIDIAエンジニアのSasha Levinがlore.kernel.orgに新たなパッチセットを投稿した。「カーネルkillswitch」と呼ばれるこの仕組みは、脆弱な関数を一時的に無効化してエラーを返すことで、正式パッチが届くまでの緊急緩和策として機能することを目的としている。ただし、このパッチは現時点でレビュー中であり、Linuxカーネルには未採用だ。提案段階の動向として紹介する。

仕組みと特徴

killswitchはsecurityfsインターフェース経由で管理者が操作する。特定の関数をkillswitch対象に指定すると、その関数は実行される代わりに即座にエラーを返す。この変更はランタイムに反映され、管理者が解除するかシステムを再起動するまで有効だ。

対象となる機能

提案が想定する対象は、AF_ALG・ksmbd・nf_tables・vsock・ax25 など「多くのシステムで日常的に使われない機能」だ。Dirty FragのESP/RxRPCもこのカテゴリに含まれうる。日常業務への影響を最小化しつつ脆弱な経路を素早く遮断することがコンセプトの核心だ。

パッチにはCopy Fail（CVE-2026-31431）のAF_ALGパスに対するセルフテストが含まれており、killswitchが実際に機能することの実証として使われている。

現在のステータス

このパッチはlore.kernel.orgでのレビュー段階にあり、2026年5月時点でLinuxカーネルには未採用だ。開発者コミュニティでは「本番環境で重要な機能を誤って無効化するリスク」や悪用可能性についての議論が続いている。モジュールブラックリスト（現行の推奨緩和策）と比較して、カーネルレベルでの一元管理ができる点が優位性だが、採用にはなお時間を要する見通しだ。

開示経緯とエンブレゴ破棄—異例の公開プロセスが示すもの

Dirty Fragの公開プロセスは、脆弱性開示（Coordinated Vulnerability Disclosure）のあり方について重要な教訓を含んでいる。

タイムライン

エンブレゴ破棄によるパッチなし状態での公開は、防御側にとって対応時間が極端に短くなるという最悪のシナリオだ。通常のCoordinated Disclosureでは「公開 = パッチ利用可能」だが、Dirty Fragでは「公開 = PoC公開、かつパッチ未提供（一部）」という状態が生まれた。その結果、公開翌日には実際の攻撃キャンペーンが記録されるに至った。

セキュリティコミュニティの反応

Hacker Newsのスレッドでは、エンブレゴ破棄のリスクと独立発見の現実についての議論が活発に行われた。「研究者が独立発見した場合の開示義務とは何か」「パッチなし公開は許容されるか」という根本的な問いは、セキュリティ研究コミュニティが長く抱えてきた未解決課題だ。

防御側の組織としては、このような「パッチなし公開」が現実に起こり得ることを前提として、脆弱性インテリジェンス（oss-security・CERT・クラウドプロバイダーのアドバイザリ）を常時監視し、パッチ待ちの間もモジュール無効化等で素早く対応できる体制を整えておくことが重要だ。

Linuxカーネルの権限昇格バイナリの悪用経路については、GTFOBins：Linuxシステム管理者のための権限昇格・脱出ツール集が攻撃者の思考パターンを理解する上で参考になる。

組織が今すべきこと—多層防御チェックリスト

Dirty Fragへの対応は単なるカーネルアップデートにとどまらず、組織全体のセキュリティポスチャを点検するきっかけとして活用できる。野生での悪用が確認された今、対応を後回しにするコストは急速に高まっている。

インフラチーム向け即時アクション

コンテナ・クラウド環境

・ECS/EKS/GKE等のマネージドKubernetesでは、コントロールプレーンはクラウドプロバイダーがパッチ適用する。ノードグループ（EC2インスタンス等）は自己管理のため手動での対応が必要だ。
・コンテナ内からホストカーネルの脆弱性を悪用できるリスクがある。特に--privilegedコンテナやhostNetwork: true設定のPodは優先的に見直すこと。
・Wiz Blogの分析によると、Kubernetesのデフォルトseccompプロファイルを持つハードニングされた環境ではリスクが低減されるが、依然としてモジュールブラックリストが推奨される。
・DockerのデフォルトseccompプロファイルはIPsec/RxRPC関連のシステムコールをブロックしないため、カスタムseccompプロファイルまたはモジュールブラックリストが必要だ。

セキュリティ運用チーム向けチェックリスト

ソフトウェア開発者向けの注意点

アプリケーション開発者はカーネルパッチを直接コントロールできないが、以下の点でリスクを下げられる。

・コンテナビルドパイプラインにカーネルセキュリティスキャンを組み込む。
・本番環境のDockerイメージにはseccomp制限を適用する。
・LPE脆弱性の悪用可能性を下げるため、アプリケーションの実行権限を最小化する（非rootユーザーで実行、CAP_NET_ADMIN等の不要なCapabilityを削除する）。

まとめ

Dirty Frag（CVE-2026-43284/CVE-2026-43500）は、Linuxカーネルのページキャッシュ書き込みという脆弱性クラスが2026年においても深刻なリスクであることを改めて示した。Copy Failに続く「Linuxカーネルを襲った第2の主要バグ」として、2つのCVEをチェーンして主要ディストリビューション全域をカバーする設計と、タイミング依存なしの決定論的な動作が特徴だ。公開翌日に野生での悪用が確認された事実は、パッチなし公開リスクを改めて浮き彫りにした。

エンブレゴ破棄という前代未聞の事態と、その翌日に記録された野生での悪用は、脆弱性インテリジェンスを受動的に待つだけでなくoss-securityやCISA KEVを積極的に監視し、パッチなし状態でも迅速に緩和策を取れる運用体制の重要性を改めて浮き彫りにした。

参照ソース

• V4bel/dirtyfrag — GitHub（公式PoC・ミティゲーション手順）
• Dirty Frag: Universal Linux LPE — oss-security（Hyunwoo Kim原文）
• Linux Kernel Hit by Second Major Bug — The Record Media
• Active attack: Dirty Frag Linux vulnerability expands post-compromise risk — Microsoft Security Blog
• Dirty Frag Linux kernel local privilege escalation vulnerability mitigations — Canonical Ubuntu Blog
• RHSB-2026-003 Dirty Frag — Red Hat Customer Portal
• Dirty Frag (CVE-2026-43284) Linux Privilege Escalation — Wiz Blog
• Dirty Frag CVE-2026-43284 Mitigation and Kernel Update — CloudLinux Blog
• Dirty Frag vulnerability fix ready for testing — AlmaLinux Blog
• Dirty Frag: a zero-day universal Linux LPE — LWN.net
• Dirty Frag and other issues in Amazon Linux kernels — AWS Security Bulletin
• Kernel killswitch proposal by Sasha Levin — lore.kernel.org
• Linux Kernel Killswitch Proposed After Recent Vulnerability Disclosures — Linuxiac
• Linux kernel maintainers pitch emergency killswitch after CopyFail and Dirty Frag chaos — The Register