Dirty Frag(CVE-2026-43284/43500/46300)とは｜Copy Fail 2の全体像とesp・rxrpc権限昇格の対策

Dirty Fragは、LinuxカーネルのIPsec ESPとRxRPC受信処理に潜むローカル権限昇格(LPE)脆弱性です。読み方は「ダーティ・フラグ」で、Fragはフラグ管理の「flag」ではなくパケット断片(fragment)を指します。研究者Hyunwoo Kim氏(@v4bel)が2026年5月7日に公開し、わずか8日前に同氏が公開したCopy Fail(CVE-2026-31431)の後継として「Copy Fail 2: Electric Boogaloo」の別名でも流通しています。非特権ユーザが標準syscallだけでroot権限を奪える(多くの場合は非特権user namespace経由でネットワーク操作権限を得る)うえ、Microsoftが公開翌日に「Dirty FragまたはCopy Failに関連しうる限定的な実地の兆候を観測した」と公表したため、Linuxを運用する組織は緊急の評価が要ります。

まとめ：Dirty Fragの要点と今すぐやること

• 何か：esp4・esp6・rxrpcのin-place復号がpage cacheを攻撃者に書き込ませるLPE。CVE-2026-43284(esp4/esp6)・CVE-2026-43500(rxrpc)・CVE-2026-46300(ESP-in-TCP、通称Fragnesia)の3件で構成される。
• 深刻度：CanonicalはCVSS 3.1で7.8(HIGH)、Red HatはImportantと評価。レース条件に依存せず決定論的に成功する点が過去のDirty Cow/Dirty Pipeより危険。
• 影響範囲：Ubuntu全リリース、RHEL 8/9/10、AlmaLinux、Oracle Linux、CloudLinux、SUSE、Debianなどほぼ全ディストリ。コンテナからホストroot奪取に直結する。
• 今すぐ：パッチ未適用ならesp4・esp6・rxrpcをblacklistして無効化(再起動不要)。IPsec VPN/AFS利用環境は業務影響を確認のうえパッチ適用を最優先する。

Dirty Fragとは何か｜読み方・Copy Fail 2という別名・発見の経緯

Dirty Fragは、Linuxカーネルが受信パケットを復号する際の性能最適化(in-place復号)を突き、非特権プロセスがpage cache上の特権データを書き換えてroot権限を得る脆弱性です。特殊なカーネル設定を必要とせず、通常の権限で開けるソケットと標準syscall(多くの場合は非特権user namespace経由で得るネットワーク操作権限を伴う)だけで成立するため、初期アクセスを許した時点でroot奪取をほぼ確実に許してしまいます。この「非特権user namespace経由で権限を得る」性質が、後述のuser.max_user_namespaces=0による緩和が効く理由でもあります。

読み方は「ダーティ・フラグ」｜dirty flag(設計パターン)とは無関係

「Dirty Frag」の読みは「ダーティ・フラグ」で、Fragはソケットバッファ(skb)のfragment(断片)領域に由来します。カタカナにすると状態管理の設計技法「dirty flag(ダーティフラグ)」と同じ音になりますが、両者は全くの別物です。GSCでも「dirty flag cve」「ubuntu dirty flag」といった綴り違いの検索が本記事に流入しており、混同が起きやすい命名だと分かります。CVEやLinuxカーネルの文脈で語られる「ダーティフラグ」は、本脆弱性Dirty Fragを指すと考えて差し支えありません。

Copy Fail 2: Electric Boogalooという別名の由来

Dirty Fragは、8日前(2026年4月29日)に公開されたCopy Fail(CVE-2026-31431)の直系の後継です。Copy Failがalgif_aead(カーネル暗号API)経由でpage cacheに単一の4バイトSTORE primitiveを与えたのに対し、Dirty FragはESP側の4バイトSTOREとRxRPC側のnamespace作成権限という2つの原始機能を連鎖させ、攻撃者が制御したオフセットでpage cache上の特権バイナリを書き換え、レース条件なしに決定論的なroot奪取まで到達します。同一研究者が短期間に「同じ攻撃クラスの続編」を出したため、映画の続編を揶揄する定番ミーム「Electric Boogaloo」を冠した「Copy Fail 2: Electric Boogaloo」という愛称が広まっています。

発見者Hyunwoo Kim氏とembargo破綻による前倒し公開

発見者は独立系研究者のHyunwoo Kim氏(GitHubハンドル@v4bel)です。本来は各ディストリビューションと調整のうえ協調的に開示される予定でしたが、embargo期間中に外部から情報が漏れたため、Kim氏はパッチもCVE番号も未確定のまま2026年5月7日にoss-security/linux-distrosメーリングリストで公開せざるを得ませんでした。この経緯により、多くのベンダーが修正版カーネルを配布する前に実用的なPoCが流通する事態となり、防御側の猶予が極端に狭まりました。

攻撃の仕組み｜in-place復号がpage cacheを汚染する構造

Dirty Fragの根本原因は、esp4・esp6・rxrpcが共通して採用するin-place復号にあります。3モジュールが別々にこの最適化を実装した結果、同型の欠陥が水平展開されました。CVE-2026-43284の起点は2017年1月のcommit cac2661c53f3、rxrpc側は2023年6月導入で、最長9年近く本番カーネルに残存していました。

esp4/esp6/rxrpcのin-place復号とpage cache書き込み

カーネルはIPsec受信パケットを復号する際、平文を新しいバッファへコピーせず受信バッファ上で直接書き換えます。この時、対象バッファがカーネル占有かユーザ空間と共有可能なpage cache由来かの所有権検証が抜けていました。その結果、復号後の平文が書き戻されたpage cacheページに非特権プロセスが参照を残せてしまい、攻撃者が制御するオフセットへの書き込み原始機能(write primitive)として悪用できます。esp4とesp6は共通のxfrm抽象を介して同じロジックを参照するため、片方だけのパッチでは解決しません。

splice/vmsplice経由で平文参照を保持する攻撃源

攻撃者はsplice(2)やvmsplice(2)でpipe bufferをsocket受信パスへ流し込み、ESPまたはRxRPCの復号を経由させます。これらは非特権で使え、コンテナでも既定で利用可能です。vmspliceを使うpage参照の保持はDirty Pipe(CVE-2022-0847)以来知られた技法で、Dirty Fragはそれをより強力な書き込みに発展させました。第3のCVE-2026-46300(Fragnesia)は、ESP-in-TCPのskb結合処理を突く変種で、Red HatのRHSB-2026-003に3件目として併記されています。

Copy Fail・Dirty Pipe・Dirty Cowとの違い（書き込み粒度と決定論性）

Dirty Fragが過去脆弱性より危険なのは、レース条件に一切依存せず、単発の書き込みで安定的にrootを取れる決定論性です。攻撃自動化ツールへの組み込みが容易になり、初期アクセスから昇格までの試行錯誤が消えます。

影響を受けるLinuxディストリビューションと自環境の確認方法

in-place復号最適化が2017年以降ほぼ全ての主要カーネル系列に取り込まれているため、影響範囲はエンタープライズLinuxのほぼ全域に及びます。Ubuntu 26.04 LTS(Resolute Raccoon)を含む全Ubuntuリリース、RHEL 8/9/10、CentOS Stream、AlmaLinux、Oracle Linux、Fedora、openSUSEが対象です。

ベンダー別の対応状況

公開時点ではNVDがCVSS数値を保留し、CanonicalやSysdigがCVSS 3.1で7.8(HIGH)と評価しました(その後NVD/CISAも7.8を付与)。Red HatはImportantと分類しています。NVD未評価の期間もHIGH相当として扱うのが妥当でした。

自環境が影響を受けるか確認するコマンド

まず稼働カーネルと脆弱モジュールのロード状況を確認し、次にパッチ適用済みかをchangelogで判定します。

uname -r
lsmod | grep -E 'esp4|esp6|rxrpc'

# RHEL/AlmaLinux/Oracle Linux系
rpm -q --changelog kernel | grep -i CVE-2026-43284

# Ubuntu/Debian系
apt changelog linux-image-$(uname -r) | grep -i CVE-2026-43284

changelogにCVE番号が現れればパッチ反映済みです。バックポート版LTSカーネルではバージョン番号だけで判断できないため、この方法でCVE記載を確認します。CVEやCPEといった脆弱性識別子の読み方はCPEとは何かも参考にしてください。

コンテナ・Kubernetes環境で攻撃面が拡大する理由

コンテナはホストカーネルを共有するため、コンテナ内の非特権ユーザがDirty Fragを悪用すればホストroot奪取に直結します。攻撃連鎖にはAF_KEY・AF_RXRPCソケットやXFRM netlink、splice/vmspliceが必要ですが、DockerやKubernetesの既定Capability・seccompでは完全には塞がれていません。とくにマルチテナントのコンテナホスティングやCI/CDの共用ランナーでは、1つのテナント/ジョブの侵害が他テナントやシークレット流出に波及します。Dockerfile段階で不要権限を落とし、Podをrestrictedなseccomp/AppArmorで固め、--cap-drop=ALLを基点に必要最小限のCapabilityだけ付与するハードニングが被害局所化に効きます。

PoC公開とroot奪取・実際の攻撃

公開されたPoCは、socket・setsockopt・bind・vmsplice・splice・sendmsgなど標準syscallの組み合わせだけで動作し、コマンド一行でroot昇格します。esp4・esp6・rxrpcがロード可能で非特権シェルがあれば、前提条件はほぼ不要です。

Microsoftが観測した実地の兆候と検知の観点

Microsoftは2026年5月8日のブログ(タイトルに「active attack」)で、suによる権限昇格を伴う限定的な実地の活動を観測し、それがDirty FragまたはCopy Failに関連する手口の可能性があると公表しました。断定的な悪用確認ではありませんが、SSH経由の低権限アカウント侵害やWebシェル、コンテナ脱出などで初期アクセスを得た攻撃者が、Dirty Fragでホストrootへ昇格しラテラルムーブメントに繋げる流れは現実的です。個々のsyscallは正当利用があるため、検知はroot以外のUIDによるAF_KEY/AF_RXRPCソケット作成、vmspliceとXFRM netlinkの短時間連続呼び出しといった相関で評価します。FalcoやSysdig Secureはこれらのランタイム検知ルールを公開済みで、既定のsystem logには痕跡が残りにくいため、eBPF/auditdによるsyscall監視が要点になります。

Dirty Fragの対策｜緊急緩和と恒久パッチ

対処は「再起動不要の緊急緩和」と「恒久パッチ」の2段階で計画します。パッチが行き渡るまでの一次緩和として、脆弱モジュールのblacklistが各ベンダー共通で推奨されています。

モジュールblacklistによる緊急緩和(再起動不要)

esp4・esp6・rxrpcを読み込めないようにし、ロード済みなら取り外します。数分で適用でき、恒久パッチまでの時間を稼げます。

printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf
rmmod esp4 esp6 rxrpc 2>/dev/null
echo 3 > /proc/sys/vm/drop_caches

ただしesp4/esp6はIPsec VPNの暗号化に必須で、無効化すると拠点間VPNやリモートアクセスVPNが即停止します。rxrpcはAndrew File System(AFS)のRPC基盤なので、AFS利用組織では分散ファイルシステムが止まります。これらを使う環境では、blacklistではなくパッチ適用を最優先に切り替えてください。逆にIPsec/AFSを使わない環境なら、blacklistの副作用はほぼゼロで有力な一次策です。

user namespace無効化とその副作用

Red HatはESP側(CVE-2026-43284)の緩和としてuser.max_user_namespaces=0によるunprivileged user namespaces無効化を提示しています。IPsecを止めずに攻撃連鎖の前提を断てますが、rootless container(Podman rootless)・Flatpak・ChromeやFirefoxのサンドボックスが動作しなくなります。またこの設定はESP側の緩和で、rxrpc側(CVE-2026-43500)はカバーしません。なおCVE-2026-43500はRed Hat製品では非対象とされるため、RHEL系ではrxrpcのblacklistは基本的に不要ですが、rxrpcが有効な他ディストリでは別途blacklistが要ります。rootless containerやサンドボックスを業務利用している環境では、user namespace無効化は実質的に選べません。

恒久パッチとLivepatchによる無停止対応

恒久策は修正済みカーネルへの更新と再起動です。24時間稼働で停止が難しい場合は、CloudLinuxのKernelCare(kcarectl --update)、Ubuntu ProのLivepatch、SUSEのKLPで再起動なしに修正を取り込めます。ただしLivepatchは対応カーネル系列に制約があり、次回再起動時には恒久パッチ済みカーネルへ置き換える運用が前提です。脆弱性対応の手順設計はNode.jsの脆弱性への対応手順のような影響確認→バージョン更新の型が他製品でも共通して使えます。

よくある質問（FAQ）

Dirty Fragの読み方は？dirty flagとの違いは？

読み方は「ダーティ・フラグ」で、Fragはパケット断片(fragment)を指します。カタカナ表記が状態管理の設計パターン「dirty flag(ダーティフラグ)」と同音になりますが無関係で、CVE文脈のダーティフラグは本脆弱性を指します。

Copy Fail 2とは何ですか？

Dirty Fragの別名です。8日前に公開されたCopy Fail(CVE-2026-31431)の後継として、続編ミーム「Electric Boogaloo」を付けた「Copy Fail 2: Electric Boogaloo」の愛称で呼ばれます。両者ともin-place最適化がpage cache所有権を曖昧にした同系統の欠陥です。

CVE番号はいくつありますか？

3件です。CVE-2026-43284(esp4/esp6)、CVE-2026-43500(rxrpc)、CVE-2026-46300(ESP-in-TCP、通称Fragnesia)。Red HatのRHSB-2026-003に3件併記されています。

Oracle LinuxやCentOSは影響を受けますか？

受けます。Oracle LinuxはELSAで更新が提供され、CentOS Stream/AlmaLinuxも対象です。サポート終了間際のCentOS 7やRHEL 7系はELS/ESM契約でのバックポート可否をベンダーに確認してください。

PoCが公開されていますが、どの程度危険ですか？

公開PoCは標準syscallのみでコマンド一行のroot昇格が可能で、レース条件に依存しないため成功率が非常に高いです。Microsoftも関連しうる限定的な実地の兆候を公表しており、パッチ未適用ホストで非特権シェルを取られた時点でrootへの昇格を前提に対応すべきです。

関連記事

• Ubuntu 26.04 LTS（Resolute Raccoon）とは｜リリース日・新機能・24.04からのアップグレード
• Dockerfileとは？書き方と主要命令・ベストプラクティスを実例で解説【入門〜実務】
• 「7-Zip」脆弱性は危険なのか｜CVE-2026-48095など主要CVEの深刻度と最新版v26.01への対処法【2026年版】
• Node.jsの脆弱性とは｜影響の確認方法と対応バージョン・アップデート手順【2026年6月最新】
• CPEとは何か？その概要と基本概念を徹底解説