---
title: "Dirty Frag（CVE-2026-43284・43500・46300）とは：Copy Fail 2の対象ディストリと修正版、KEV追加とAndroidの対応"
url: "https://www.issoh.co.jp/tech/details/12089/"
published: 2026-05-13
updated: 2026-11-13
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# Dirty Frag（CVE-2026-43284・43500・46300）とは：Copy Fail 2の対象ディストリと修正版、KEV追加とAndroidの対応

Dirty Frag（ダーティ・フラグ、通称Copy Fail 2）は、LinuxカーネルのIPsec ESP（esp4・esp6）とRxRPC（rxrpc）の受信処理を突くローカル権限昇格の脆弱性です。一般ユーザーの権限から`/usr/bin/su`などのページキャッシュを書き換え、rootを取れます。同じ経路の後続Fragnesia（CVE-2026-46300）は10月28日にCISAの悪用確認済み脆弱性カタログ（KEV）へ入り、11月にはAndroidの月例更新にも43284の修正が載りました。3件の違い、ディストリ別の修正版、確認コマンドと緩和策を、2026年11月13日時点の一次情報で整理します。

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

- **中身**：esp4・esp6・rxrpcが、ページキャッシュと共有したメモリをその場で復号して書き換える欠陥。CVE-2026-43284（ESP）とCVE-2026-43500（RxRPC）が本体で、CVE-2026-46300（Fragnesia）とCVE-2026-43503（DirtyClone）が同じ部品の後続。
- **悪用**：Microsoftが5月8日に、Dirty FragまたはCopy Failを使った可能性のある限定的な攻撃活動を報告。46300は10月28日にKEVへ追加され、PHPのCVE-2026-109618・109619と連鎖してrootでWebシェルを動かせるとCISAが明記した。
- **対象**：Ubuntu、Debian、RHEL 8〜10と互換ディストリ、Amazon Linux、Androidなど。RHEL 6・7は3件とも非該当、RHELはrxrpcを出荷しないため43500も非該当。
- **修正版**：Ubuntu 24.04は6.8.0-124.124、22.04は5.15.0-181.191、RHEL 9は5.14.0-687.10.1.el9\_8で対象の2件が直る（Ubuntuは一般向けGAカーネルの版）。Androidはセキュリティパッチレベル2026-11-05以降。
- **つなぎ**：IPsecとAFSを使わないホストはesp4・esp6・rxrpcをブロック。IPsecを止められないホストは非特権user namespaceを無効化し、43500の影響を受ける環境ではrxrpcのブロックも併用する。

Copy Fail（CVE-2026-31431）の暫定策であるalgif\_aeadのブロックでは、Dirty Fragは防げません。Copy Fail側の修正版は[CVE-2026-31431（Copy Fail）のディストリ別修正版と緩和策](/tech/details/11972/)で扱っています。以下、名前の由来から順に根拠を示します。

## Dirty Fragの読み方とCopy Fail 2という別名

Dirty Fragの「Frag」は、カーネルのソケットバッファ（`struct sk_buff`）が持つfrag（断片）領域のことです。発見者のHyunwoo Kim氏は[GitHubのREADME](https://github.com/V4bel/dirtyfrag)で、Dirty Pipeの系譜にあり、sk\_buffのfragを「汚す」バグなのでこの名前にしたと説明しています。

### 読み方「ダーティ・フラグ」と設計パターンのdirty flagの違い

カタカナにすると、状態管理の設計手法「dirty flag（変更済みフラグ）」と同じ音になります。「dirty flag ubuntu」「dirty flag android」で脆弱性情報を探している場合は、CVE番号を併記するとDirty Fragの情報を区別しやすくなります。脆弱性を指す「ダーティフラグ」はDirty Fragの表記違いである可能性がありますが、CVE-2026-43284・43500などの番号で対象を確認してください。

### 「Copy Fail 2: Electric Boogaloo」の由来と発見者

Copy Failを見つけたのはTheoriのTaeyang Lee氏で、Dirty Fragの発見者とは別人です。Kim氏はREADMEで、Copy Failが研究の出発点だったと書いています。「Copy Fail 2: Electric Boogaloo」は、別の研究者が公開済みの修正コミットから作ったPoCのリポジトリ名です。本人は[oss-securityへの投稿（2026年5月7日）](https://www.openwall.com/lists/oss-security/2026/05/07/12)で、embargoからの漏えいではなく公開コミットを読んで作ったと説明しています。Red Hatもこの通称を併記しています。

公開も異例で、外部要因でembargoが崩れたため、Kim氏はメンテナの求めに応じて5月7日にパッチもCVE番号も無いまま文書を出しました。CVEレコードの公開日は5月8日（43284）と5月11日（43500）です。

## 3つのCVEとDirtyCloneの違い：成立条件とCVSS

同じ系統でも、攻撃に必要な前提が違います。どの緩和策がどれに効くかは、この表で決まります。CVSSと影響開始版は[CVE.orgのkernel.org CNAレコード](https://www.cve.org/CVERecord?id=CVE-2026-43284)の値です。

| CVE            | 通称         | 部品              | 前提             | CNAのCVSS | 影響開始 |
| -------------- | ---------- | --------------- | -------------- | -------- | ---- |
| CVE-2026-43284 | Dirty Frag | esp4・esp6       | user namespace | 8.8      | 4.11 |
| CVE-2026-43500 | Dirty Frag | rxrpc           | rxrpcの読み込み     | 7.8      | 5.3  |
| CVE-2026-46300 | Fragnesia  | ESP-in-TCP      | user namespace | 7.8      | 3.9  |
| CVE-2026-43503 | DirtyClone | sk\_buffの断片移し替え | 対象モジュールの読み込み   | 8.8      | 3.9  |

ESP側は、ネットワーク設定の権限を得るために非特権user namespaceを作る必要があります。UbuntuのようにAppArmorでその作成を制限していると成立しません。RxRPC側はnamespaceが要らない代わりに、rxrpcを積むディストリが限られます。ただしUbuntuでは既定で読み込まれます。2件を組み合わせると互いの穴を埋め、主要ディストリのどれでもrootに届く、というのがDirty Fragの全体像です。レース条件に頼らない論理バグで、失敗してもカーネルが落ちにくい点はCopy Failと同じです。

43284のCVSSは、kernel.org CNAがスコープ変更ありの8.8、CISA-ADPとRed Hatが7.8です。Fragnesiaは5月13日にV12のWilliam Bowling氏が公表し、[kernel.orgのGreg Kroah-Hartman氏が採番を告知](https://www.openwall.com/lists/oss-security/2026/05/13/5)しました。DirtyCloneは6月25日にJFrogが公表したもので、[Canonicalの解説](https://ubuntu.com/blog/dirtyclone-linux-vulnerability-fixes-available)によるとモジュールのブロックを済ませていれば影響を受けません。

## 悪用状況の時系列：Microsoftの観測から46300のKEV追加まで

### 2026年5月：Microsoft Defenderが観測したsu経由の権限昇格

[Microsoftのセキュリティブログ（5月8日、14日更新）](https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/)は、Defenderが「limited in-the-wild activity」を観測したと書いています。SSHで入った攻撃者がELFバイナリを置いて実行し、直後に`su`経由でrootへ上がる流れで、Dirty FragとCopy Failのどちらかと見られています。同じ記事は14日時点で、Fragnesiaの実攻撃は観測していないとしていました。検知名は「Exploit:Linux/DirtyFrag.A」などです。

### 2026年10月28日：CVE-2026-46300のKEV追加とPHP2Shellとの連鎖

CISAは10月28日、[KEVカタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)に46300を加えました。登録内容は次のとおりです。

| 項目          | KEVの登録値                              |
| ----------- | ------------------------------------ |
| 脆弱性名        | Missing Initialization of a Variable |
| CWE         | CWE-456                              |
| 追加日         | 2026年10月28日                          |
| 連邦機関の是正期限   | 2026年10月31日                          |
| フォレンジック調査   | Yes                                  |
| ランサムウェアでの利用 | Unknown                              |

説明文には、PHPのCVE-2026-109618・109619と連鎖させるとPHPのWebシェルを置き、rootでコマンドを実行できると書かれています。PHPの2件は認証なしで遠隔からコードを実行できる欠陥で、10月26日にKEVへ入りました。つまり「ローカルの一般ユーザーが前提だから後回し」という判断は、PHPを公開しているサーバーでは成り立ちません。PHP側の修正版は[PHP2Shell（CVE-2026-109618・109619）の影響範囲と修正版](/tech/details/18738/)にまとめています。是正期限が3日しかないのは、CISAが[BOD 26-04の基準](/tech/details/18233/)で期限を決めているためです。

2026.11.10版のKEVに、43284・43500・43503は載っていません。ただしCISAが付けたSSVCの悪用評価は、43284が「poc」、46300が「active」です。43284と46300は同じESPの経路で緩和策も共通なので、片方だけ直す分け方に意味はありません。

### KEV追加を受けた更新の優先順位

- **最優先**：インターネットに公開したPHPアプリが動き、カーネルが46300の修正版未満のホスト。PHPとカーネルを同じ作業枠で更新し、先に侵害の痕跡を調べる。
- **次点**：コンテナ基盤やCI/CDの共用ランナーなど、他人のコードを動かすホスト。
- **通常枠**：社内向けで外からコードを持ち込まれにくいホスト。月次の更新で追いつく。

KEVは46300に「フォレンジック調査を要する」を付けています。再起動でページキャッシュの改ざんは消えますが、置かれたWebシェルやrootで足された設定は残ります。痕跡の探し方は後半の検知の章で示します。KEVを軸に更新の順番を決める運用は[KEVで優先度を決めるパッチ管理の手順](/tech/details/19309/)で解説しています。

## ディストリ別の影響と修正版（2026年11月時点）

判断はディストリと更新チャネルに対応するパッケージ版で行います。RHELのEUS・E4Sやリアルタイムカーネルには別の修正版があるため、下表の通常カーネルの値を一律に適用しないでください。上流の版番号は、自前ビルドや上流追従のディストリ向けの目安です。

### Ubuntu・Debianで3件を直したカーネルの版

Ubuntuの値は[UbuntuのCVEトラッカー](https://ubuntu.com/security/CVE-2026-46300)、Debianの値は[Debianセキュリティトラッカー](https://security-tracker.debian.org/tracker/CVE-2026-43284)から取りました。

| リリース               | 43284・43500                    | 46300          |
| ------------------ | ------------------------------ | -------------- |
| Ubuntu 26.04       | 7.0.0-22.22                    | 7.0.0-22.22    |
| Ubuntu 24.04       | 6.8.0-124.124                  | 6.8.0-124.124  |
| Ubuntu 22.04       | 5.15.0-181.191                 | 5.15.0-181.191 |
| Ubuntu 20.04       | 5.4.0-231.251                  | 5.4.0-233.253  |
| Ubuntu 18.04       | 43284：4.15.0-251.263／43500：非該当 | 4.15.0-253.265 |
| Debian 13 trixie   | 6.12.86-1                      | 6.12.90-1      |
| Debian 12 bookworm | 6.1.170-3                      | 6.1.174-1      |

表のUbuntu欄はGAカーネル（ソースパッケージlinux）の修正版です。22.04以降のGAは同じ版で3件とも修正されていますが、HWE・AWS・Azureなどのカーネルは、それぞれのソースパッケージの修正版で判定します。20.04と18.04は46300だけ後の版で直ったので、5月の更新で止めたホストは46300が残っている可能性があります。20.04以前はUbuntu Pro（ESM）での配布で、16.04（4.4.0-283.317）と14.04（3.13.0-214.265）にも46300の修正が出ています。7.2系の26.10は3件とも非該当です。Ubuntu 26.04の位置づけは[Ubuntu 26.04 LTSのリリース日と24.04からのアップグレード](/tech/details/10901/)で確認できます。

### RHEL・AlmaLinux・Rocky Linux・CentOS 7の対象可否と修正版

Red Hatは[RHSB-2026-003](https://access.redhat.com/security/vulnerabilities/RHSB-2026-003)で3件をまとめて扱い、いずれもImportantです。[CVE-2026-46300のページ](https://access.redhat.com/security/cve/CVE-2026-46300)の修正版は次のとおりで、43503も同じ版で直っています。

| 製品       | 43284                    | 46300・43503              |
| -------- | ------------------------ | ------------------------ |
| RHEL 10  | 6.12.0-124.56.1.el10\_1  | 6.12.0-211.16.1.el10\_2  |
| RHEL 9   | 5.14.0-611.55.1.el9\_7   | 5.14.0-687.10.1.el9\_8   |
| RHEL 8   | 4.18.0-553.124.1.el8\_10 | 4.18.0-553.125.1.el8\_10 |
| RHEL 6・7 | 非該当                      | 非該当                      |

RHELはrxrpcを出荷していないため、43500は全バージョンで非該当です。RHEL 7とCentOS 7も3件とも対象外です。停止できないホストには、RHEL 8・9でkpatch-patchが配られました（43284分はRHEL 9.6 EUSで5月18日、RHEL 8などで5月20日、46300分は6月4日以降）。

AlmaLinuxは独自の修正版を先に出しており、版番号がRHELより小さくても修正済みです。[AlmaLinuxの告知](https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/)では、46300を含む版は8が4.18.0-553.124.3.el8\_10、9が5.14.0-611.54.5.el9\_7、10が6.12.0-124.56.3.el10\_1以降です。版の大小だけで判定すると誤ります。AlmaLinux 9・10は、Develリポジトリの`kernel-modules-partner`を入れたときだけrxrpc経由（43500）でも影響を受け、8はrxrpcをビルドしていません。Rocky Linuxは自社のエラータで、3件のCVE番号を含む版を確かめてください。

### Oracle Linux（UEK）・Amazon Linux・SUSEの修正版

Oracle Linuxは、RHEL互換カーネルとは別に独自のUEK（Unbreakable Enterprise Kernel）を配っており、対象範囲がRHELと違います。[Oracle LinuxのCVEページ](https://linux.oracle.com/cve/CVE-2026-43284.html)では、RHELでは非該当の7系でも、UEKなら43284（ELSA-2026-50258ほか、5月9日〜）と46300（ELSA-2026-50288ほか、5月25日〜）の修正が出ています。RHELでは全版非該当の43500も、9・10のUEKは対象で、ELSA-2026-50259などで直っています。Oracle Linuxは`uname -r`に「uek」が入るかで、どちらのカーネルが動いているかを先に確かめてください。

Amazon Linuxは、[セキュリティ速報2026-027-AWS](https://aws.amazon.com/security/security-bulletins/2026-027-aws/)（5月7日公開、27日更新）で43284と43500を扱い、46300は2026-029-AWSに分けています。影響を受けるのは4.14・5.4・5.10・5.15・6.1・6.12・6.18の各カーネルで、修正版はAL2023の6.1ならALAS2023-2026-1694、AL2の5.10ならALAS2KERNEL-5.10-2026-118のように、カーネル系列ごとのアドバイザリに載っています。AWSは更新できない場合の代わりとして、モジュールのブロックに加え`sysctl -w kernel.modules_disabled=1`（次の再起動まで元に戻せない）も挙げています。SUSEは、SUSEのCVEデータベースでCVE番号ごとに製品別の修正版を確かめてください。

### kernel.orgの系列別の修正版

6.6系以降の表掲載系列では、各行の最も新しい修正版以上で3件とも修正済みです（6.12系なら6.12.91以上、7.0系なら7.0.10以上）。5.10・5.15・6.1系は43500の修正版が表で確認できないため、この表だけでは3件の修正完了を判定できません。

| 系列    | 43284    | 43500   | 46300・43503 |
| ----- | -------- | ------- | ----------- |
| 5.10系 | 5.10.255 | 記載なし    | 5.10.257    |
| 5.15系 | 5.15.205 | 記載なし    | 5.15.208    |
| 6.1系  | 6.1.171  | 記載なし    | 6.1.174     |
| 6.6系  | 6.6.138  | 6.6.140 | 6.6.141     |
| 6.12系 | 6.12.87  | 6.12.88 | 6.12.91     |
| 6.18系 | 6.18.28  | 6.18.29 | 6.18.33     |
| 7.0系  | 7.0.5    | 7.0.6   | 7.0.10      |

5.10〜6.1系の43500は、ディストリ側のバックポートで確かめます。7.1以降は3件とも修正済みです。

## AndroidとDirty Frag：2026年11月のセキュリティ情報で修正

Googleは[Androidセキュリティ情報 2026年11月版](https://source.android.com/docs/security/bulletin/2026/2026-11-01)（11月2日公開、6日更新）の「2026-11-05 セキュリティ パッチ レベル」のカーネル部品に、CVE-2026-43284（A-510777270、権限昇格、重大度High、Networking）を載せました。6月から11月の版に、43500と46300は載っていません。

43284だけが載った理由は、攻撃チェーンを公開した[LSPosedのLSPromise](https://github.com/LSPosed/LSPromise)の説明で分かります。43500に要るRxRPCはAndroidの汎用カーネル（GKI）で無効になっており、43284に要るxfrm-ESPは使えるものの、一般のアプリからはSELinuxで使用が禁じられています。そこでLSPromiseは、Android 17で入ったTelecomの欠陥（CVE-2026-49881、2026年9月に修正）でまず`system_server`の権限を取り、そこから43284でカーネルに届く構成を取りました。検証機は初期のAndroid 17正式版を載せたPixel 10です。

端末で確かめるには、設定の「セキュリティとプライバシー」などにある「セキュリティ パッチ レベル」（機種によって「Androidのセキュリティアップデート」）の日付を見ます。2026年11月5日以降なら43284の修正を含みます。2026年11月1日の表示だけでは、5日分に分類されたカーネル修正の適用は保証されません。Pixel向けの別の月例情報には、6〜11月の時点で3件とも載っていません。

つまりAndroidでは、端末に入った悪意あるアプリが別の欠陥と組み合わせて初めてrootに届きます。パッチレベルを2026年11月5日以降に上げるのが本筋で、更新が届かない端末では出所の不明なアプリを入れないことが実質的な防御になります。

## 自環境のカーネルが影響を受けるか確認するコマンド

判定の対象はホストのカーネルです。コンテナはホストのカーネルを共有するので、コンテナの中のディストリ情報では判断できません。版の見方は[Linuxのバージョン確認コマンド（os-releaseとuname -r）](/tech/details/17895/)で解説しています。

```
# 稼働中のカーネルと、対象モジュールの読み込み状況
uname -r
grep -E '^(esp4|esp6|rxrpc|esp4_offload|esp6_offload) ' /proc/modules || echo "対象モジュールは読み込まれていない"

# Ubuntu / Debian：稼働中カーネルのパッケージ版を修正版と比べる
# 例は Ubuntu 24.04 の GA generic カーネル（6.8.0系）専用。HWE・クラウド用は系列ごとの修正版に置き換える
fixed=6.8.0-124.124
case "$(uname -r)" in
  6.8.0-*-generic)
    pkgver=$(dpkg-query -W -f='${Version}' "linux-image-$(uname -r)")
    if dpkg --compare-versions "$pkgver" ge "$fixed"; then echo "修正版以上: $pkgver"; else echo "修正版未満: $pkgver"; fi ;;
  *) echo "判定対象外の系列: $(uname -r)（HWEやクラウド用はその系列の修正版で比べる）" ;;
esac

# Ubuntu で変更履歴を見るなら linux-modules 側
apt changelog "linux-modules-$(uname -r)" | grep -E -m3 'CVE-2026-(43284|43500|46300)'

# RHEL / Rocky / AlmaLinux 8〜10：稼働中のカーネルに限定して変更履歴を引く
rpm -q --changelog "kernel-core-$(uname -r)" | grep -E -m3 'CVE-2026-(43284|46300)'
```

Ubuntuで`linux-image-…`の変更履歴を引くと、署名用パッケージ（linux-signed）の履歴が返り、CVE番号が出てこないことがあります。モジュール本体を含む`linux-modules-…`を指定してください。RHEL系の`rpm -q --changelog kernel`は、まだ起動していない新しいカーネルの記録まで拾います。`kernel-core-$(uname -r)`に絞れば、いま動いているカーネルだけを見られます。更新を入れても再起動するまでは古いカーネルが動いている点にも注意してください。

## 侵害の痕跡を調べる手順と、Dirty Frag系の検知

46300のKEV登録は、CISAのフォレンジック初動調査（Forensics Triage）の対象です。PHPを公開しているホストで、更新の作業に入る前に最低限確かめるコマンドは次のとおりです。

```
# 1. 公開ディレクトリで内容の最終更新日時が直近14日以内のPHPファイルを洗い出す
sudo find /var/www -type f -name '*.php' -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %u %p\n' | sort

# 2. Webサーバーの実行ユーザーが動かしているシェルを探す
ps -eo user,pid,ppid,lstart,cmd | awk '$1 ~ /^(www-data|apache|nginx)$/ && $9 ~ /(^|\/)(sh|bash|dash|zsh|ksh|ash|fish)$/ {print}'

# 3. これからの悪用に備え、user namespaceの作成とAF_RXRPC(33)ソケットを記録する
sudo auditctl -a always,exit -F arch=b64 -S unshare -F 'auid>=1000' -F 'auid!=unset' -k dirtyfrag_ns
sudo auditctl -a always,exit -F arch=b64 -S unshare -F euid=$(id -u www-data) -k dirtyfrag_web   # Webサーバーの実行ユーザーに合わせる
sudo auditctl -a always,exit -F arch=b64 -S socket -F a0=33 -k dirtyfrag_rxrpc
sudo ausearch -k dirtyfrag_ns -i --start today | tail -n 20
```

手順1で見覚えの無いファイルが見つかったら、ホストを隔離してから調べます。手順の詳細は[Webシェルの検知・除去の手順](/tech/details/18314/)にあります。

手順3の`unshare`はブラウザやrootlessコンテナも呼ぶため、記録は大量に出ます。最初のunshareルールはログインUIDが1000以上で未設定ではない利用者の呼び出しを記録します。CLONE\_NEWUSERの指定は絞り込んでいないため、user namespaceの作成以外も含み、掲載ルールではclone・clone3や32ビットのシステムコール経由の作成は記録しません。ログインUIDが未設定のWebサービスは、2行目のように実効UIDを条件にした別ルールで拾います。`auditctl`のルールは再起動で消えるので、残すなら`/etc/audit/rules.d/`に書きます。製品の検知ルールも出ています。Elastic Security Labsは[Copy FailとDirty Fragの解説](https://www.elastic.co/security-labs/copy-fail-dirtyfrag-linux-page-bugs-in-the-wild)で「Namespace Manipulation Using Unshare」など5本のルールを示しました。Microsoft Defender for Cloudにも「Potential exploitation of dirtyfrag vulnerability detected」という警告があります。実行時の不審な挙動を拾う仕組みは[Falcoのランタイム脅威検知とルール運用](/tech/details/17238/)で整理しています。

## Dirty Fragの対策：つなぎの緩和と恒久パッチ

対処は「更新までのつなぎ」と「恒久パッチ」の2段階です。修正版へ更新して再起動を済ませたら、緩和策は外しても構いません。

### esp4・esp6・rxrpcのブロックとIPsecへの影響

IPsecとAFSを使わないホスト向けの手順です。[Canonicalの手順](https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available)を基に、ブロック、取り外し、確認の3段で書いています。

```
# 1. 今後の読み込みを禁止する
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | sudo tee /etc/modprobe.d/dirty-frag.conf
# Ubuntu / Debian は起動初期の読み込みも止めるため initramfs を作り直す
sudo update-initramfs -u -k all

# 2. 読み込み済みなら取り外す（使用中なら失敗する）
sudo rmmod esp4 esp6 rxrpc 2>/dev/null

# 3. 外れたかを確かめる。残っていれば再起動で反映する
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "まだ読み込まれている" || echo "読み込まれていない"
```

esp4とesp6はIPsecのESPを担います。使用中のモジュールは`rmmod`が拒否するので、動いているIPsec接続がこの操作で切れることはありません。ただし次の起動からIPsecが動かなくなります。拠点間VPNやstrongSwanを動かすホストでは、再起動の時点でVPNが止まります。rxrpcはAFSの通信基盤なので、AFSを使う組織ではファイル共有が止まります。IPsecの仕組みは[IPsecの仕組みとAH・ESP・IKEの役割](/column/details/13464/)で解説しています。研究者のREADMEが挙げる`echo 3 > /proc/sys/vm/drop_caches`（カーネルがcleanと扱うページキャッシュなどの破棄）は一時的にディスクI/Oを増やすので、本番機では再起動の枠で済ませるほうが安全です。

### user namespaceの無効化でIPsecを止めずに防ぐ方法

IPsecを止められないホスト向けに、Red Hatは非特権user namespaceの無効化を示しています。43284と46300に効き、IPsecは動いたままです。

```
echo "user.max_user_namespaces=0" | sudo tee /etc/sysctl.d/dirty-frag.conf
sudo sysctl --system
sysctl user.max_user_namespaces   # 0 なら反映済み
```

副作用として、Podmanのrootlessコンテナ、Flatpak、ChromeやFirefoxのサンドボックスが動かなくなります。rxrpc側の43500はnamespaceを使わないので防げません。RHEL系は43500が非該当なのでこれだけで足りますが、Ubuntuではrxrpcのブロックを併用します。rootlessコンテナを業務で使うホストでは選べない手段なので、更新を前倒しするしかありません。

### 恒久パッチの適用とライブパッチを選ぶ条件

```
# Ubuntu / Debian
sudo apt update && sudo apt upgrade && sudo reboot
# RHEL / Rocky / AlmaLinux
sudo dnf update kernel && sudo reboot
```

再起動後、前の章の確認コマンドで稼働中の版が修正版以上になったことを確かめて完了です。止められないホストには、Ubuntu ProのLivepatch、RHELのkpatch-patch、SUSEのLive Patchingがあります。ただし対応する系列が限られ、次の計画停止で正規の更新へ置き換える前提です。

4月末のCopy Failから6月のDirtyCloneまで、同じ系統の公表が2か月で4回続きました。CVEごとに追うより、カーネル更新を月次で回す運用に切り替えるほうが手戻りが少なくなります。ESPやrxrpcを使わないサーバーは、修正後もブロックを残す判断が合理的です。公開サーバーが多く、どこにPHPやIPsecが残っているか把握しきれない場合は、一創の[脆弱性診断・セキュリティ診断](/service/system/vulnerability/)で外部からの洗い出しと修正の優先順位付けを相談できます。

## コンテナ・Kubernetes環境でDirty Fragが危険な理由

コンテナはホストのカーネルを共有するため、コンテナ内の非特権ユーザーがDirty Fragを使うとホストのページキャッシュを書き換えられます。Canonicalはコンテナ脱出につながりうると説明しており、CI/CDの共用ランナーでは1つのジョブの侵害が同じノードの他のジョブやシークレットに及びます。ホストのカーネル更新を済ませたうえで、ESP側の前提であるuser namespaceの作成をコンテナに許さない設定が被害を狭めます。Podには`seccompProfile.type: RuntimeDefault`を設定し、採用ランタイムのプロファイルが対象のnamespace作成を制限することを確認したうえで、各コンテナの`securityContext.capabilities.drop`に`["ALL"]`を設定し、必要な権限だけを`add`で戻してください。イメージ側の権限の絞り方は[Dockerfileの書き方とベストプラクティス](/tech/details/3315/)で扱っています。

## よくある質問

### Copy Fail 2とは何ですか？Copy Failと同じ脆弱性ですか？

Dirty Fragの通称です。Copy Fail（CVE-2026-31431）とは別の欠陥で、発見者も別人です。名前は、公開済みの修正コミットから別の研究者が作ったPoCのリポジトリ名「Copy Fail 2: Electric Boogaloo」に由来します。Copy Failの緩和策（algif\_aeadのブロック）ではDirty Fragを防げません。

### Dirty FragのCVE番号はいくつありますか？

本体は2件で、CVE-2026-43284（esp4・esp6）とCVE-2026-43500（rxrpc）です。Red HatのRHSB-2026-003は、後続のFragnesia（CVE-2026-46300）を加えた3件をまとめて扱っています。6月に名前の付いたDirtyClone（CVE-2026-43503）も同じ部品の欠陥で、多くのディストリは46300と同じ版で直しています。

### Dirty FragのPoCは公開されていますか？

研究者のGitHubで公開されています。研究者はレース条件に頼らず成功率が高いと説明しています。Microsoftは5月に、Dirty FragまたはCopy Failを使った可能性のある限定的な攻撃活動を観測しました。検証で動かす場合も、本番と同じネットワークに置かないでください。

### RHEL 7やCentOS 7は影響を受けますか？

Red HatはRHEL 6・7を3件とも非該当としています。RHEL 8・9・10は43284と46300が対象で、43500はrxrpcを出荷していないため非該当です。AlmaLinuxは独自の修正版を先に出しているので、版番号の大小ではなくアドバイザリの版で判定してください。

### Androidスマホは対策が必要ですか？

43284はAndroidセキュリティ情報2026年11月版で修正されました。設定で「セキュリティ パッチ レベル」が2026年11月5日以降になっていれば修正済みです。更新が届かない端末では、出所の不明なアプリを入れないことが防御になります。

## 関連記事

- [CVE-2026-31431（Copy Fail）とは｜ディストリ別の修正版・GKEとEKSの対応と緩和策](/tech/details/11972/)
- [PHP2Shellとは：CVE-2026-109618・109619の影響範囲と修正版、悪用の実態と更新できない場合の設定【2026年10月】](/tech/details/18738/)
- [パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順](/tech/details/19309/)
- [Webシェルとは？仕組み・代表例と検知・除去の手順をTomcat・PHP・IISのコマンド例で解説](/tech/details/18314/)
- [IPsecとは？仕組み・AH/ESP/IKEとVPNでの使い方、SSL/TLSとの違いと選び方を解説](/column/details/13464/)

---

出典: [Dirty Frag（CVE-2026-43284・43500・46300）とは：Copy Fail 2の対象ディストリと修正版、KEV追加とAndroidの対応](<https://www.issoh.co.jp/tech/details/12089/>)（株式会社一創）
