Dirty Flag CVE-2026-43284 / CVE-2026-43500 対応まとめ

2026年5月、Linux カーネルのローカル権限昇格脆弱性「Dirty Frag」が公開されました。

一部の情報では “Dirty Flag” と表記されていることもありますが、研究者の公開リポジトリや Ubuntu などの公式情報では “Dirty Frag” が主な呼び名です。

対象の CVE は2つです。

CVE-2026-43284: xfrm-ESP Page-Cache Write
CVE-2026-43500: RxRPC Page-Cache Write

先日の Copy Fail と同じく、読み取りしかできないはずのファイルのページキャッシュをメモリ上で書き換え、そこから root 権限につなげるタイプの脆弱性です。

Copy Fail の記事を書いたばかりなのに、もう次が来ました。つらい。

CVE-2026-31431「Copy Fail」対応まとめ | Lazy Developer

2026年4月末に公開された Linux カーネルのローカル権限昇格脆弱性 CVE-2026-31431「Copy Fail」について、何が起きているのか、どの環境が影響を受けるのか、対応方針を整理します。PoC が公開されており、共有サーバーや CI 環境では高優先で対応すべき内容です。

lazy-developer.jp

AIの進化によって、今後もポコポコ出てくる予感。

概要

項目	内容
通称	Dirty Frag（Dirty Flag / Copy Fail 2 と呼ばれることもある）
CVE	CVE-2026-43284 / CVE-2026-43500
種別	Linux カーネルのローカル権限昇格
影響箇所	`esp4`、`esp6`、`rxrpc`、`xfrm`、`splice()` 周辺
攻撃条件	ローカルの非特権ユーザー権限
公開日	2026-05-07
CVSS	CVE-2026-43284 は 8.8 High（kernel.org CNA / Ubuntu）、CVE-2026-43500 は Ubuntu 評価で 7.8 High

研究者 Hyunwoo Kim 氏のリポジトリでは、公開当初から PoC が出ています。

ここで嫌なのは、単なる「クラッシュするかも」ではなく、非特権ユーザーから root まで行ける点です。

共有サーバー、CI ランナー、コンテナ実行基盤を持っているなら、かなり優先度を上げたほうがいいです。

なにが起きているか

雑にいうと、splice() などでページキャッシュ由来のページをネットワーク送信側の sk_buff の fragment に差し込みます。

その後、受信側のカーネル処理が「これは自分が安全に書き換えていいバッファだ」と扱って、in-place で復号処理をしてしまう。

結果として、本来は読み取り専用で参照しているだけのファイルのページキャッシュが、メモリ上で書き換わります。

ディスク上のファイルが書き換わるわけではありません。

でも、次にそのファイルを読むプロセスからは、書き換わったページキャッシュが見えます。

Copy Fail と同じく、ここが厄介です。/usr/bin/su や /etc/passwd のような重要ファイルがページキャッシュ上で改変されると、オンディスクのチェックサムだけ見ても気づけない可能性があります。

2つの脆弱性で穴を埋め合っている

Dirty Frag は CVE が2つに分かれています。

CVE-2026-43284: xfrm-ESP

IPsec ESP の受信処理で、共有された skb fragment に対して in-place 復号が走る問題です。

研究者側の説明では、これにより任意の 4 バイトを書き込めるプリミティブが作れます。

かなり強いです。

ただし、XFRM SA を登録するには CAP_NET_ADMIN が必要です。攻撃側は user namespace / network namespace を使ってそこを突破します。

なので、Ubuntu のように unprivileged user namespace 周りが制限されている環境では、この経路だけでは刺さらないケースがあります。

CVE-2026-43500: RxRPC

もう1つが RxRPC 側です。

こちらは xfrm-ESP ほど自由に値を書けるわけではありませんが、攻撃者が RxRPC key を使って復号結果をある程度コントロールできます。

しかも、user namespace を作れることに依存しません。

研究者側は、この2つを組み合わせることで、それぞれの弱点を埋めて「主要ディストリで root を取れる」形にした、と説明しています。

要するに、片方だけ見て「うちは大丈夫」と判断しにくいです。

Copy Fail の緩和策だけでは防げない

ここはかなり重要です。

Copy Fail のときは algif_aead を無効化する暫定策がありました。

でも Dirty Frag は algif_aead を通りません。

Dirty Frag の xfrm-ESP 経路は Copy Fail と同じ種類のページキャッシュ書き換えにつながりますが、入口が違います。

つまり、Copy Fail 対応で algif_aead を blacklist していても、Dirty Frag には別対応が必要です。

「前回の設定を入れたから終わり」ではないです。

影響を受ける環境

研究者リポジトリでは、CVE-2026-43284 は 2017年1月17日のコミット以降、CVE-2026-43500 は 2023年6月8日のコミット以降が範囲とされています。

実際にテストされた環境として、Ubuntu 24.04.4、RHEL 10.1、openSUSE Tumbleweed、CentOS Stream 10、AlmaLinux 10、Fedora 44 などが挙げられています。

Ubuntu は 14.04 LTS から 26.04 LTS までを影響ありとして扱っています。

特に危ないのはこのあたりです。

複数ユーザーが入る開発サーバー、踏み台、共有シェル
self-hosted GitHub Actions / GitLab Runner / Jenkins agent
コンテナ実行基盤、Kubernetes ノード
VPS やクラウド VM
ホスティングサーバー

Microsoft も、SSH、Web shell、コンテナ、低権限アカウント侵害後の権限拡大に使われるリスクを挙げています。

なお、コンテナ環境についてはホスト側のローカル権限昇格リスクとして見るべきですが、Ubuntu は「コンテナ escape の PoC はまだ公開されていない」と説明しています。

最初の侵入口ではなく、侵入された後に root を取られるための道具として使われる、という見方をしたほうがいいです。

対応方針

まずカーネル更新

本命は修正済みカーネルへの更新です。

mainline には CVE-2026-43284 の修正として f4c50a4034e6、CVE-2026-43500 の修正として aa54b1d27fe0 が入っています。

ただし、公開直後は CVE-2026-43500 側のパッチ状況が流動的だったため、実運用では必ず各ディストリビューションの advisory と配布カーネルの changelog を確認したほうがいいです。

ただし、mainline に入ったことと、自分のディストリビューションの配布カーネルにバックポートされたことは別です。

実際の運用では、各ベンダーのセキュリティアドバイザリを見て、パッケージ更新と再起動までやります。

# Ubuntu / Debian 系
sudo apt update
sudo apt full-upgrade
sudo reboot

# RHEL / AlmaLinux / Rocky / Fedora 系
sudo dnf upgrade --refresh
sudo reboot

# 起動中カーネルの確認
uname -r

カーネルを入れただけで、古いカーネルで動き続けていたら意味がないです。

再起動後の uname -r まで確認して終わりです。

暫定で esp4 / esp6 / rxrpc を止める

すぐに更新できない場合は、影響するモジュールを読み込ませない暫定策があります。

Ubuntu が案内しているのはこの方向です。

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirty-frag.conf"
sudo update-initramfs -u -k all
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

さらに、PoC 実行後や改変済みページキャッシュが疑われる場合は、ページキャッシュを捨てるか再起動します。

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

ただし、これは副作用があります。

esp4 / esp6 は IPsec ESP で使われます。StrongSwan などの VPN を使っている環境では、普通に通信が壊れる可能性があります。

rxrpc は AFS などで使われます。

なので、本番で叩く前に「IPsec VPN を使っていないか」「AFS / RxRPC 依存がないか」は確認したほうがいいです。

片方だけ止めても足りない

Ubuntu の注意にもある通り、esp4 / esp6 だけ止めても rxrpc が残っていれば片方の経路が残ります。

逆も同じです。

暫定緩和をするなら3つまとめて止める前提で考えたほうがいいです。

確認コマンド

自分のサーバーで、対象モジュールがロード済みかを見るだけならこれです。

grep -E '^(esp4|esp6|rxrpc) ' /proc/modules || true

無効化設定が入っているかを見るならこれ。

cat /etc/modprobe.d/dirty-frag.conf 2>/dev/null

カーネル組み込みやベンダーパッチ有無まで厳密に見るなら、ディストリビューションの CVE ページやパッケージ changelog を確認する必要があります。

# Ubuntu / Debian 系の例
apt changelog linux-image-$(uname -r) | grep -E 'CVE-2026-43284|CVE-2026-43500|Dirty Frag' -i

# RHEL 系の例
rpm -q --changelog kernel | grep -E 'CVE-2026-43284|CVE-2026-43500|Dirty Frag' -i

ここでヒットしないから即アウト、とは限りません。

クラウド向けカーネルや HWE カーネルだとパッケージ名が違うことがあります。

最終的にはベンダーの advisory を見るのが確実です。

優先度

個人的には、Copy Fail と同じく高優先で扱います。

理由はシンプルです。

ローカルの非特権ユーザーから root に上がれる
PoC が公開されている
競合状態に依存しない、成功率が高いタイプとして説明されている
共有ホスト、CI、コンテナ基盤で刺さると被害が広がる
Copy Fail の緩和策では防げない
ページキャッシュ改変なので、ディスク上の検査だけでは見逃す可能性がある

個人の VPS で自分しかログインしないなら、攻撃条件は多少きつく見えます。

とはいえ、Web アプリの脆弱性や漏れた SSH 鍵で一度低権限を取られた後、root まで行かれる材料になります。

SSH ポート変更や fail2ban のような入口対策とは別に、カーネル更新もちゃんとやるべきやつです。

VPS 契約したら、とりあえず ssh ポートは変えておけ | Lazy Developer

この記事では、VPS を契約した直後に最低限やっておきたい ssh のポート変更と、ufw を使ったファイアウォール設定について備忘録として記載します。サーバーをインターネットに公開すると、SSH への不正アクセス試行やブルートフォース攻撃は普通に飛んできます。 22 番のまま運用していると、とにかく雑なアクセス試行

lazy-developer.jp

まとめ

Dirty Frag は、Copy Fail の延長線にあるページキャッシュ書き換え系のローカル権限昇格です。

名前が似ているだけではなく、脅威の質もかなり似ています。

ただし入口は algif_aead ではなく、esp4 / esp6 / rxrpc 側です。

Copy Fail の対応をしたサーバーでも、Dirty Frag は別腹で見ないといけません。

まずはカーネル更新。すぐに更新できないなら、IPsec / AFS への影響を確認したうえで esp4、esp6、rxrpc の無効化を検討。

この順番で見るのがよさそうです。