Dirty Frag CVE-2026-43284｜Linux カーネル特権昇格の緩和手順

はじめに

2026 年 5 月 7 日、研究者 Hyunwoo Kim 氏によって、Linux カーネルに存在する新たなローカル特権昇格（LPE）脆弱性 Dirty Frag が公表されました。本脆弱性は CVE-2026-43284（xfrm-ESP Page-Cache Write） と CVE-2026-43500（RxRPC Page-Cache Write） という 2 つの CVE で構成されるチェイン型の脆弱性で、ローカルの一般ユーザー権限から root 権限への昇格が単一コマンドで成立し得る深刻な内容です。

さらに、Microsoft Defender の観測によれば、本脆弱性に関連する実環境での限定的な攻撃が既に確認されており、SSH アクセスや Web シェル経由で初期侵入を許した環境では、Dirty Frag が「侵害の横展開・恒久化」のための強力な道具として用いられる可能性が高まっています。修正パッチも CVE-2026-43284 については 2026 年 5 月 8 日に Linux Kernel Organization からリリース済みである一方、CVE-2026-43500 については本記事執筆時点でパッチ未公開という状況です。

本記事では、Dirty Frag の技術的な概要、影響を受ける Linux ディストリビューションとカーネルモジュール、攻撃シナリオの全体像、そして暫定的な緩和策と適用後の整合性確認手順までを実務目線で整理します。

Dirty Frag（CVE-2026-43284 / CVE-2026-43500）の概要

Dirty Frag は、Linux カーネルのネットワーキングおよびメモリフラグメント処理コンポーネントに存在する 2 つのページキャッシュ書き込みプリミティブを組み合わせたローカル特権昇格脆弱性です。攻撃者は脆弱なカーネルが動作するシステムで、ローカル実行権限を得てさえいれば、レースコンディションに依存しない決定論的な手法で root 権限を取得できます。

脆弱性の基本情報

Microsoft Security Blog は本脆弱性について以下のように説明しています。

参考: Microsoft Security Blog – Active attack: Dirty Frag Linux vulnerability expands post-compromise risk
“A newly disclosed Linux local privilege escalation vulnerability known as ‘Dirty Frag’ enables escalation from an unprivileged user to root through vulnerable kernel networking and memory-fragment handling components, including esp4, esp6 (CVE-2026-43284), and rxrpc (CVE-2026-43500).”
（新たに公開された “Dirty Frag” として知られる Linux のローカル特権昇格脆弱性により、esp4、esp6（CVE-2026-43284）および rxrpc（CVE-2026-43500）を含む、脆弱なカーネルネットワーキングおよびメモリフラグメント処理コンポーネントを介して、未特権ユーザーから root への昇格が可能となります。）
https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/

Dirty Frag を構成する 2 つの脆弱性は、それぞれ次のように整理できます。

CVSS スコアはいずれも 7.8（HIGH） とされており、ローカルアクセス前提という制約はあるものの、ローカル実行権限さえあれば確実に成立するという点で実害が大きい脆弱性です。

攻撃の技術的な仕組み

両脆弱性に共通するのは、「カーネルが排他所有していないページフラグメントに対して、復号処理を in-place で実行してしまう」という設計上の欠陥です。具体的には、splice(2) / sendfile(2) / MSG_SPLICE_PAGES を通じてソケットバッファに渡されたパイプページに対し、esp4 / esp6 / rxrpc の受信パスが直接復号を行う際、攻撃者が同じページへの参照を保持し続けることでページキャッシュの内容を書き換えることが可能となります。

参考: AlmaLinux Security Advisory – Dirty Frag
“The bug lives in the in-place decryption fast paths of esp4, esp6, and rxrpc: when a socket buffer carries paged fragments that are not privately owned by the kernel (e.g. pipe pages attached via splice(2)/sendfile(2)/MSG_SPLICE_PAGES), the receive path decrypts directly over those externally-backed pages, exposing or corrupting plaintext that an unprivileged process still holds a reference to.”
（バグは esp4、esp6、rxrpc の in-place 復号ファストパスに存在します。ソケットバッファがカーネルに排他所有されていないページフラグメント（例: splice(2)/sendfile(2)/MSG_SPLICE_PAGES でアタッチされたパイプページ）を運ぶ際、受信パスはそれら外部所有のページに対して直接復号を行い、未特権プロセスが参照を保持し続ける平文を漏えい・破壊します。）
https://almalinux.org/blog/2026-05-07-dirty-frag/

実際の攻撃の流れとしては、/usr/bin/su などの SUID バイナリのページキャッシュを直接書き換え、setuid(0); setgid(0); execve("/bin/sh") 相当の小さなスタブを差し込むことで、次回 su を実行した際に攻撃者がそのまま root シェルを取得する、という形が公開 PoC で確認されています。ディスク上の元ファイルは書き換えられず、メモリ上のキャッシュのみが改ざんされるため、従来のファイル整合性チェックでは検知が困難な点も特徴です。

CopyFail（CVE-2026-31431）との違いと共通点

Dirty Frag は、約 1 週間前の 2026 年 5 月 1 日に公開された CopyFail（CVE-2026-31431） の同系列にあたる脆弱性です。両者は「ページキャッシュへの書き込みプリミティブを介した特権昇格」という基本構造を共有しますが、攻撃面と緩和策の互換性において重要な違いがあります。

特に注意すべきは、CopyFail の緩和策（algif_aead のブラックリスト化）を適用済みであっても、Dirty Frag に対しては依然として脆弱である点です。研究者 Kim 氏自身が「Dirty Frag は algif_aead モジュールの有無に関係なく成立する」と明言しており、CopyFail への対処が完了している環境でも、別途 Dirty Frag への緩和策を追加で実施する必要があります。

既に限定的な攻撃が観測されている

本脆弱性のもう一つの重要なポイントは、公開時点で既に攻撃が観測されている点です。

参考: Microsoft Security Blog – Limited In-The-Wild Exploitation
“Microsoft Defender is currently seeing limited in-the-wild activity where privilege escalation involving ‘su’ is observed, and which may be indicative of techniques associated with either ‘Dirty Frag’ or ‘Copy Fail’.”
（Microsoft Defender は現在、’su’ を介した特権昇格を伴う限定的な実環境での活動を観測しており、これは “Dirty Frag” または “Copy Fail” に関連する手法を示唆している可能性があります。）
https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/

加えて、本脆弱性は 2026 年 4 月 30 日に Linux カーネルチームへ報告された後、第三者によって禁輸（エンバーゴ）期間が破られて公開された経緯があります。これは公開時点で既に悪用が始まっていた可能性を示唆しており、ディストリビューション側のパッチ提供よりも先に PoC が GitHub 等で出回るという、ディフェンダーにとっては不利な状況下で対処を進める必要がある脆弱性です。

影響を受ける Linux ディストリビューションと対象モジュール

Dirty Frag は、メインライン Linux カーネルに長期間混入していた欠陥に由来するため、主要なエンタープライズディストリビューションのほぼすべてが影響対象となります。一方で、CVE-2026-43284（ESP 側）と CVE-2026-43500（RxRPC 側）では影響範囲が異なるため、自社環境がどちらの CVE に該当するかを正しく切り分けることが重要です。

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

Microsoft Security Blog では、本脆弱性の影響対象として以下のディストリビューションが挙げられています。

参考: Microsoft Security Blog – Active attack: Dirty Frag Linux vulnerability expands post-compromise risk
“Affected environments may include Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE, and OpenShift deployments.”
（影響を受ける環境には Ubuntu、RHEL、CentOS Stream、AlmaLinux、Fedora、openSUSE、および OpenShift のデプロイメントが含まれる可能性があります。）
https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/

AlmaLinux の公式アドバイザリによれば、ESP 側の欠陥となる CVE-2026-43284 を導入したコミットは 2017 年 1 月、RxRPC 側の CVE-2026-43500 を導入したコミットは 2023 年 6 月にまで遡るため、約 9 年分のカーネルバージョンに影響が及ぶとされています。

2 つの CVE で影響範囲が異なる点に注意

研究者 Kim 氏の公開資料によれば、2 つの CVE はディストリビューションごとのハードニング状況によって攻撃成立条件が異なるため、攻撃者は両者をチェインして「ディストリビューション間の死角」を相互にカバーする設計となっています。

CVE-2026-43284（ESP 側）

ユーザー名前空間（user namespace）の作成権限が必要。Ubuntu では AppArmor によって未特権ユーザーの名前空間作成が制限されているため、この経路はブロックされる。

CVE-2026-43500（RxRPC 側）

通常のユーザー権限のみで成立。ただし rxrpc.ko モジュールが多くのディストリビューションでは標準ビルドに含まれていない。

整理すると、自社環境がどちらの CVE に該当しやすいかは次のような傾向となります。

「Ubuntu だから ESP 経路は防がれている」と単純に判断するのではなく、RxRPC 経路で攻撃が成立する点に留意することが重要です。逆に、RHEL 8 系で kernel-modules-partner を導入していない環境では、ESP 経路への対処に集中できます。

影響を受けるカーネルモジュール

本脆弱性で直接的に攻撃面となるカーネルモジュールは以下の 3 つです。

esp4 / esp6 は IPsec VPN を構成する上で必須の変換モジュールであり、strongSwan や Libreswan を用いた IPsec ゲートウェイ運用環境では常用されています。一方の rxrpc は AFS クライアント向けのモジュールで、一般的な Web サーバや業務サーバではほぼ利用されないものの、ディストリビューションによってはデフォルトでカーネル組み込みとなっています。

なお、AWS のセキュリティ情報では、関連する ipcomp4 / ipcomp6（IP Compression）モジュールも併せて確認対象として挙げられています。

参考: AWS Security Bulletin – Dirty Frag and other issues in Amazon Linux kernels
“Check if the modules are loaded on the host for all affected modules with the following command: lsmod | grep -E ‘esp4|esp6|ipcomp4|ipcomp6|rxrpc'”
（影響を受けるすべてのモジュールがホスト上でロードされているかを以下のコマンドで確認してください。）
https://aws.amazon.com/security/security-bulletins/rss/2026-027-aws/

自社環境が該当するかの確認方法

自社の Linux ホストが脆弱な状態にあるかどうかは、以下の手順で確認できます。

① カーネルバージョンの確認

$ uname -r

出力例: 5.14.0-503.40.1.el9_5.x86_64

② 脆弱モジュールのロード状態の確認

$ lsmod | grep -E '^(esp4|esp6|rxrpc)'

出力に該当モジュールが表示された場合、現在カーネルに当該モジュールがロードされており、攻撃面が存在する状態となります。何も出力されない場合は、現時点ではロードされていません（ただし、カーネルの自動ロード機構によって任意のタイミングでロードされ得る点には注意が必要です）。

③ モジュールがビルド済みかどうかの確認

$ find /lib/modules/$(uname -r) -name 'esp4*' -o -name 'esp6*' -o -name 'rxrpc*'

該当ファイルが見つかれば、現在ロードされていなくてもカーネル側にモジュールとして存在しており、必要に応じて読み込まれる可能性があります。

④ AlmaLinux 9 / 10 の場合の追加確認

AlmaLinux 9 / 10 で RxRPC 側に該当するかどうかは、追加パッケージの導入有無で判別できます。

$ rpm -q kernel-modules-partner

package kernel-modules-partner is not installed と表示される場合、CVE-2026-43500 の影響対象外です。

参考: AlmaLinux Security Advisory – Dirty Frag
“CVE-2026-43500 — the rxrpc half — additionally affects AlmaLinux 9 and 10, but only on systems that have installed the kernel-modules-partner package.”
（CVE-2026-43500（rxrpc 側）は AlmaLinux 9 および 10 にも影響しますが、kernel-modules-partner パッケージを導入しているシステムに限ります。）
https://almalinux.org/blog/2026-05-07-dirty-frag/

ご利用のディストリビューションによっては、uname -r の出力フォーマットや、モジュール配置パスの細部が異なる場合があります。本番適用前には、利用中のディストリビューションの公式アドバイザリで最新の確認手順を参照することが推奨されます。

攻撃シナリオと観測された侵害事例

Dirty Frag は単体で初期侵入を成立させる脆弱性ではなく、「ローカル実行権限を持つ立場」からの特権昇格に利用されるポスト侵害型の脆弱性です。そのため、本脆弱性のリスク評価では「攻撃者がローカル実行権限を獲得し得る経路」と「特権昇格後にどのような被害が広がるか」を併せて整理することが重要となります。

初期侵入から特権昇格までの一般的な経路

Microsoft は、本脆弱性が悪用される典型的な経路として以下を列挙しています。

参考: Microsoft Security Blog – Exploitation scenarios
“Threat actors may leverage Dirty Frag after obtaining local code execution through several common intrusion paths, including: Compromised SSH accounts, Web-shell access on internet-facing applications, Container escapes into the host environment, Abuse of low-privileged service accounts, Post-exploitation activity following phishing or remote access compromise.”
（脅威アクターは、SSH アカウントの侵害、インターネット公開アプリケーションへの Web シェル配置、コンテナからホスト環境へのエスケープ、低権限サービスアカウントの悪用、フィッシングやリモートアクセス侵害後の事後活動など、複数の一般的な侵入経路でローカルコード実行を獲得した後、Dirty Frag を悪用する可能性があります。）
https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/

これらの初期侵入経路に共通するのは、「攻撃者が一般ユーザー権限でシェル相当の実行能力を獲得している」という前提です。Dirty Frag はこの前提さえ整えば、レースコンディションのような不安定要素を伴わずに root 昇格を成立させてしまいます。

Microsoft Defender が観測した実攻撃の流れ

Microsoft Defender は、本脆弱性に関連する可能性のある実環境攻撃を観測しており、その攻撃チェーンを次のように整理しています。

1. 外部からの SSH 接続によって対話的シェルを取得
2. ELF バイナリ ./update をステージング・実行し、即座に su を介した特権昇格を発火
3. 昇格後、GLPI（IT 資産管理ツール）の LDAP 認証ファイルを vim で改ざん（.swp ファイルが痕跡として残存）
4. GLPI ディレクトリおよびシステム構成の偵察、エクスプロイト用アーティファクトの確認
5. PHP セッションファイルへのアクセス、複数セッションの削除および強制 wipe
6. 残存セッションデータの読み取りによる機微情報の窃取

参考: Microsoft Security Blog – Limited In-The-Wild Exploitation
“After gaining elevated access, the actor modifies a GLPI LDAP authentication file (evidenced by a .swp file from vim), performs reconnaissance of the GLPI directory and system configuration, and inspects an exploit artifact.”
（昇格後、攻撃者は GLPI の LDAP 認証ファイルを改ざん（vim の .swp ファイルがその痕跡）し、GLPI ディレクトリおよびシステム構成の偵察を行い、エクスプロイト用アーティファクトを確認します。）
https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/

注目すべきは、特権昇格後の挙動が「LDAP 認証ファイルの改ざん」「セッションデータへのアクセス」といった、ID 基盤と機密データに直結する操作に向かっている点です。これは単純な暗号通貨マイナーの設置などではなく、より広範な認証情報窃取・侵害の横展開を狙った活動であることを示唆しています。

コンテナ環境・サービスアカウントが狙われる理由

Dirty Frag は、ホスト OS だけでなくコンテナワークロードにとっても重大なリスクとなります。デフォルト構成の Docker / containerd / 大半の Kubernetes Pod では、攻撃に必要なソケットファミリ（AF_KEY、AF_RXRPC、XFRM netlink）の利用がブロックされておらず、コンテナ内で侵害が起きた場合にホストの root 権限まで一気に昇格され得ることが指摘されています。

特にリスクが高いと考えられる構成は以下の通りです。

• マルチテナント環境: CI/CD ランナー、コンテナビルドファーム、共有開発サーバなど
• Web アプリケーション基盤: 脆弱なアプリケーションを介して Web シェルが配置されるリスクがある環境
• Kubernetes Pod: seccomp プロファイルでカスタム制限を設けていない、デフォルト構成の Pod
• サービスアカウント運用: 低権限のサービスアカウント（apache、nginx、tomcat など）が稼働するシステム

特にコンテナ環境では、ホスト側カーネルが脆弱である限り、コンテナ単独の対処では防御が成立しない点を理解しておくことが重要です。コンテナワークロードを稼働させているホスト OS のカーネルパッチ適用が、本脆弱性への根本的な対処となります。

緊急対処と緩和策

Dirty Frag は CVE-2026-43284 については 2026 年 5 月 8 日にメインラインカーネルで修正済みである一方、CVE-2026-43500 については本記事執筆時点でパッチ未提供という状況です。各ディストリビューションが順次バックポートを提供している段階のため、当面は「カーネルパッチ適用」と「暫定的な緩和策」を併用することが現実的な対処方針となります。

推奨される恒久対策: カーネルパッチの適用

最も確実な対処は、各ディストリビューションが提供する修正済みカーネルへのアップグレードと再起動です。

参考: Microsoft Security Blog – Mitigation guidance
“The Linux Kernel Organization released patches, which are linked at the National Vulnerability Database (NVD), to fix CVE-2026-43284 on May 8, 2026. Customers who have not applied these patches are urged to do so as soon as possible.”
（Linux Kernel Organization は 2026 年 5 月 8 日に CVE-2026-43284 を修正するパッチをリリースしました。NVD にリンクされています。未適用の場合は速やかな適用が推奨されます。）
https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/

主要ディストリビューションでのパッケージ更新コマンドの例は以下の通りです。ただし、実際のパッケージ名や反映タイミングはディストリビューションのリリース状況に依存するため、必ず利用中のディストリビューションの公式アドバイザリで最新の手順を確認してください。

# Ubuntu / Debian 系
$ sudo apt update && sudo apt upgrade

# RHEL / Rocky / AlmaLinux / Fedora / Amazon Linux 系
$ sudo dnf clean metadata && sudo dnf upgrade

# openSUSE 系
$ sudo zypper refresh && sudo zypper update kernel-default

カーネルパッケージの更新後は、新しいカーネルでブートするための再起動が必要です。Live Patch（KernelCare、Canonical Livepatch 等）を契約している環境では、再起動なしでパッチ適用できる場合があります。

参考: AlmaLinux Security Advisory – Dirty Frag
“Patched kernels are now rolling out to production repositories/mirrors. Just run: sudo dnf clean metadata && sudo dnf upgrade, sudo reboot.”
（パッチ済みカーネルは本番リポジトリ / ミラーへ展開中です。sudo dnf clean metadata && sudo dnf upgrade を実行し、再起動してください。）
https://almalinux.org/blog/2026-05-07-dirty-frag/

暫定的な緩和策 1: 脆弱モジュールの読み込み無効化（modprobe.d）

カーネルパッチがまだ反映できない、または CVE-2026-43500 のように修正未提供の脆弱性をカバーするための主たる緩和策が、/etc/modprobe.d/ 配下の設定ファイルで esp4 / esp6 / rxrpc モジュールの読み込みをブロックする方法です。

設定ファイルの作成

$ sudo tee /etc/modprobe.d/dirtyfrag.conf >/dev/null <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

この install ... /bin/false という構文は、modprobe が該当モジュールをロードする代わりに /bin/false を実行するよう指示するもので、カーネル側の自動ロード機構（request_module 等）からの呼び出しも含めてブロックできる点が特徴です。単純な blacklist 行ではユーザー操作によるロードしか抑止できないため、本件の緩和策としては install 行による方法が広く推奨されています。

参考: Red Hat Documentation – Prevent a kernel module from loading automatically
“The install line simply causes /bin/false to be run instead of installing a module.”
（install 行は、モジュールをロードする代わりに /bin/false を実行させます。）
https://access.redhat.com/solutions/41278

既に読み込まれているモジュールのアンロード

設定ファイルを作成しても、既にメモリ上にロードされているモジュールには影響しません。次のコマンドでアンロードを試みます。

$ sudo modprobe -r esp4 esp6 rxrpc 2>/dev/null

IPsec トンネルがアクティブな状態では esp4 / esp6 のアンロードが失敗します（Module is in use エラー）。その場合は、IPsec サービスを一時停止するか、後述の運用影響を踏まえて再起動による反映を計画する必要があります。

運用影響の事前確認（重要）

esp4 / esp6 / rxrpc は次の用途で利用されているため、本緩和策の適用はそれらの機能を停止させる前提となります。

自社ホストが IPsec ゲートウェイ / トンネル終端として動作している場合、esp4 / esp6 の無効化は VPN 接続を停止させます。

なお、Red Hat の OpenShift 公式 KB では、IPsec 利用有無を以下のコマンドで確認する手順が案内されています。

$ oc get network.operator cluster -o jsonpath='{.spec.defaultNetwork.ovnKubernetesConfig.ipsecConfig}{"\n"}'

参考: Red Hat Customer Portal – How to mitigate the “Dirty Frag” CVE-2026-43284 in OpenShift 4
“IMPORTANT: do not apply this mitigation if IPsec is in use (it is required to check not only the cluster but also the workloads).”
（重要: IPsec を利用している場合は本緩和策を適用しないでください。クラスタだけでなくワークロードについても確認が必要です。）
https://access.redhat.com/solutions/7142250

暫定的な緩和策 2: ユーザー名前空間の作成制限（ESP 側のみ）

CVE-2026-43284（ESP 側）は、未特権ユーザーによる user namespace の作成権限を前提としています。sysctl で名前空間作成を禁止することで、ESP 経路の攻撃をブロックできます。

$ sudo sysctl -w user.max_user_namespaces=0

ただし、本設定には次のような副作用があります。

• CVE-2026-43500（RxRPC 側）には効果がない
• ルートレスコンテナランタイム（Podman の rootless モードなど）が動作不能になる
• Flatpak、サンドボックスブラウザなどが影響を受ける

そのため、この設定は modprobe によるモジュール無効化と組み合わせて適用するのが妥当です。単独で用いる場合は、自社環境でルートレスコンテナ等を運用していないことを必ず確認した上で適用してください。

暫定的な緩和策 3: ローカルシェル / SSH アクセスの制限

Dirty Frag はローカル実行権限を前提とする脆弱性であるため、「シェル相当の実行能力を持つアカウントを最小化する」ことが根本的な攻撃面の縮小につながります。具体的には次のような対策が考えられます。

• SSH 公開鍵認証への一本化、パスワード認証の禁止
• AllowUsers / AllowGroups による SSH 接続可能アカウントの制限
• 共有開発サーバ、CI ランナー上での一般ユーザーシェル発行の見直し
• sudo 権限の付与状況の棚卸し

暫定的な緩和策 4: コンテナ環境の堅牢化

コンテナ環境では、ホスト OS 側のカーネルパッチが根本対処である点を踏まえつつ、Pod / コンテナレベルでも以下の制限を強化することが推奨されます。

• seccomp プロファイルで AF_KEY、AF_RXRPC、XFRM netlink などの不要なソケットファミリ・netlink プロトコルを制限
• CAP_NET_ADMIN などの不要な Linux capability を Pod から剥奪
• 既知の Pod セキュリティ標準（Pod Security Standards）の Restricted プロファイル相当への準拠
• 信頼境界を越えた Pod 間通信について、不要な特権昇格経路がないかの再点検

暫定的な緩和策 5: 特権昇格挙動の監視強化

修正適用と並行して、特権昇格を伴う異常挙動の検知ルールを強化することが推奨されます。

参考: Microsoft Security Blog – Microsoft Defender coverage
Microsoft Defender Antivirus: Exploit:Linux/DirtyFrag.A / Exploit:Linux/DirtyFrag.B / Trojan:Linux/DirtyFrag.Z!MTB ほか
Microsoft Defender for Endpoint: Suspicious SUID/SGID process launch
Microsoft Defender for Cloud: Potential exploitation of dirtyfrag vulnerability detected
https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/

EDR 製品を別途利用している環境でも、su 経由の予期しない権限遷移、splice / vmsplice 関連の syscall を未特権プロセスが多用するパターン、SUID バイナリの異常な実行などをアラート対象に組み込むことが望ましいと考えられます。

緩和策の組み合わせ方

各緩和策は単独では限界があるため、「カーネルパッチ → モジュール無効化 → 名前空間制限 → アクセス制限 → 監視強化」を多層で重ねることが推奨されます。優先順位の目安としては次の通りです。

1. カーネルパッチが利用可能なら即時適用（CVE-2026-43284 については 5 月 8 日以降パッチ提供開始）
2. パッチ未適用期間は modprobe による esp4 / esp6 / rxrpc の無効化（IPsec 利用環境では事前検証が前提）
3. ESP 経路に対する追加対策として user namespace 制限（ルートレスコンテナ未利用環境のみ）
4. コンテナ環境では seccomp / capability の見直し
5. 特権昇格挙動の監視・検知ルールの強化

CVE-2026-43500 についてはパッチ未提供のため、当面は modprobe による rxrpc 無効化が唯一の現実的な防御策となる点に留意が必要です。

緩和適用後の整合性確認とログ調査

Dirty Frag のエクスプロイトは、SUID バイナリ（/usr/bin/su 等）のページキャッシュをメモリ上で書き換える動作を行うため、ディスク上の元ファイルは改変されません。この特性のため、緩和策を適用した後も「既にページキャッシュが改ざんされた状態」が残存している可能性を考慮する必要があります。

ページキャッシュのクリア（drop_caches）の意義と注意点

緩和適用後は、ページキャッシュのクリアを行うことが推奨されています。これは、エクスプロイトによってキャッシュに書き込まれた悪意あるバイナリスタブを一掃する目的があります。

$ sync
$ echo 3 | sudo tee /proc/sys/vm/drop_caches

drop_caches に書き込む値の意味は次の通りです。

本件の緩和では、改ざんされた可能性のあるバイナリのページキャッシュを確実にクリアするため、3 を指定するのが推奨されます。sync を先に実行するのは、書き込み待ちのダーティページをディスクに反映してからキャッシュ解放を行うためです。

参考: Microsoft Security Blog – Post-mitigation integrity verification
“Cache clearing can temporarily increase disk I/O and impact production performance and should be evaluated carefully before deployment.”
（キャッシュクリアは一時的にディスク I/O を増加させ、本番のパフォーマンスに影響を及ぼす可能性があるため、デプロイ前に慎重に評価することが推奨されます。）
https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/

本番運用中のデータベースサーバや高 I/O ワークロードでは、drop_caches 実行直後にディスク I/O が急増し、応答性能が一時的に悪化することが想定されます。メンテナンスウィンドウ内での実施、または計画的な再起動による反映が望ましい運用となります。

重要ファイルの整合性確認

ページキャッシュのクリアに加えて、SUID バイナリや認証関連ファイルの整合性をディスク上の正規パッケージと照合することも推奨されます。

RPM 系での整合性確認

$ sudo rpm -Va | grep -E '^.{8}\s+(/usr/bin/su|/usr/bin/sudo|/usr/bin/passwd)'

何も出力されなければ、対象ファイルはインストール時の状態と一致しています。

Debian / Ubuntu 系での整合性確認

$ sudo debsums -c 2>&1 | grep -E '(/usr/bin/su|/usr/bin/sudo|/usr/bin/passwd)'

事前に debsums パッケージのインストールが必要となります（sudo apt install debsums）。

ただし、本脆弱性の特性上、ディスク上のファイルは改変されないため、これらのコマンドでは攻撃の有無を直接判定できない点に注意してください。整合性確認はあくまで補助的な調査手段となります。

侵害痕跡（IoC）の調査ポイント

Microsoft Defender が観測した攻撃シナリオを踏まえると、以下の観点でログ・痕跡を調査することが侵害判定に有効です。

特に、vim の .swp ファイルは攻撃者が編集中に異常終了した場合に残存する痕跡として有効な手掛かりになります。Microsoft の観測事例でも、GLPI の LDAP 認証ファイルの近くに .swp ファイルが残っていたことが報告されています。

侵害が疑われる場合は、該当ホストをネットワークから隔離した上で、認証情報のローテーション・SSH 鍵の再発行・関連サービスのセッション無効化を並行して実施することが推奨されます。

まとめ

Dirty Frag（CVE-2026-43284 / CVE-2026-43500）は、Linux カーネルの esp4 / esp6 / rxrpc コンポーネントに存在するページキャッシュ書き込みプリミティブを悪用した、決定論的なローカル特権昇格脆弱性です。実環境での限定的な攻撃が既に観測されており、公開 PoC も出回っています。本記事の要点を整理します。

• 影響範囲は広範: Ubuntu、RHEL、CentOS Stream、AlmaLinux、Fedora、openSUSE、OpenShift など主要ディストリビューションのほぼすべてが対象。ESP 側は 2017 年、RxRPC 側は 2023 年導入の欠陥に由来し、約 9 年分のカーネルバージョンに影響
• 2 つの CVE がチェインする: CVE-2026-43284（ESP）はユーザー名前空間の作成権限が必要（Ubuntu では AppArmor で制限）、CVE-2026-43500（RxRPC）は通常権限で成立。2 つを組み合わせることでディストリビューションごとのハードニングを相互にカバーする設計
• CopyFail の緩和策では防げない: algif_aead のブラックリスト化済みの環境でも Dirty Frag は成立する。研究者自身が明示しており、別途対処が必要
• 恒久対策はカーネルパッチ: CVE-2026-43284 は 2026 年 5 月 8 日にメインライン修正済み。CVE-2026-43500 はパッチ未提供のため、modprobe による rxrpc 無効化が当面の唯一の緩和策
• 暫定緩和の主軸は modprobe.d による esp4 / esp6 / rxrpc のブラックリスト化。IPsec VPN を稼働させているホストでは esp4 / esp6 の無効化が VPN 停止につながるため、事前の IPsec 利用有無の確認が前提
• 緩和適用後も drop_caches によるページキャッシュクリアが必要。本脆弱性はメモリ上のキャッシュのみを書き換えるため、ディスク上の整合性確認だけでは侵害の有無を判定できない
• IoC 調査では vim の .swp ファイル、不審な ELF バイナリ、PHP セッションの大量削除、su 経由の異常な権限遷移などを重点的に確認することが有効

以上、最後までお読みいただきありがとうございました。