Dirty Frag (CVE-2026-43284 / 43500) — Copy Failの後継、ESP/RxRPC経由でroot奪取するLinux LPE

はじめに

2026-05-07、Linuxカーネルにまたしても普遍的なローカル権限昇格脆弱性が公開された。Dirty Frag(CVE-2026-43284 / CVE-2026-43500)。Hacker News では当日 758pts と他を引き離して首位に立ち、openwall oss-security では発見者 Hyunwoo Kim 自らがエクスプロイトコード込みで投稿している。先週話題になったばかりの Copy Fail (CVE-2026-31431) の “後継” であり、Copy Fail で配られたミティゲーションをすでに適用したシステムであっても無防備なまま、という嫌な仕様だ。

本記事では、Dirty Frag の本体である ESP/RxRPC の in-place 復号がページキャッシュ書き込みプリミティブに化ける仕組み を腑分けし、Copy Fail との違い、コンテナ環境への影響、運用者が今すぐ取れる具体的な対処を整理する。

何が起きたのか — 2つのCVEと”Universal LPE”の意味

Dirty Frag は単一のバグではなく、page-cache write 系の脆弱性ファミリー を指す呼称である。中身は2つの独立した CVE だ。

  • CVE-2026-43284 — xfrm-ESP (IPsec の esp4 / esp6) における in-place 復号の不備。mainline では f4c50a4034e6 で修正済み。
  • CVE-2026-43500 — RxRPC (AFS で使われる Rx プロトコル + Rxkad 認証) の同種の問題。本稿執筆時点でアップストリームパッチは未リリース。

Canonical の評価は両者とも CVSS 3.1 で 7.8(HIGH)。Ubuntu の影響範囲は 14.04 LTS から 26.04 LTS までほぼ全バージョン、RHEL 10.1 / openSUSE Tumbleweed / CentOS Stream 10 / AlmaLinux 10 / Fedora 44 など主要ディストロを横断的に巻き込む。ESP のコードパスは 2017 年頃から、RxRPC は 2023 年以降に問題が混入していたとされ、年単位で潜伏していた点も Copy Fail と同じ構造だ。

なお発見者の Hyunwoo Kim は openwall への投稿時点で 完全動作する PoC(192バイトの ELF ペイロード+カーネルトリガ) を併記している。つまり「概念実証」ではなく、コピペで root が降ってくる段階の公開だ。

技術的な仕組み — page-cache write primitive と in-place 復号

Dirty Frag の本質は、Wiz Blog が “page-cache-backed memory that is not exclusively owned by the kernel” と表現する一点に集約される。

通常、splice(2) や sendfile(2) で渡されるパイプページや mmap 由来のページは、カーネルが排他所有していない共有領域 だ。esp4/esp6/rxrpc の受信パスは、これらの paged buffer に対して その場で復号 (in-place decryption) を実行する。攻撃者の手順は概ねこうだ。

  1. splice() で読み取り専用ファイル(例:/usr/bin/su や /etc/passwd)のページキャッシュをパイプに流し、IPsec / RxRPC ソケットへ送り込む。
  2. カーネルは「このページは復号バッファ」と誤認し、暗号文を平文で書き戻す。
  3. 平文を制御できる攻撃者は、ページキャッシュ上の /usr/bin/su 先頭160バイトを静的x86_64の root シェル ELF で上書き、もしくは /etc/passwd の root エントリを空パスワードに改変して PAM nullok を踏ませる。

レース条件に依存した Dirty Pipe / Copy Fail 系と違い、Dirty Frag は 決定論的 に成立する。Wiz は “deterministic and highly reliable, similar to previous vulnerabilities like Copy Fail and Dirty Pipe” と評しているが、より正確には Copy Fail よりさらに安定した書き込みプリミティブ と言える。

そして決定打は Copy Fail 用の algif_aead ブラックリストが効かない ことだ。Dirty Frag は AF_ALG ではなく ESP/RxRPC を入口にするため、攻撃面そのものが別系統である。先週 algif_aead を modprobe で潰して胸を撫で下ろしたサーバ運用者は、もう一度シャツの裾を直す必要がある。

エンジニアへの影響と即時ミティゲーション

実害が出る現場は大きく3層に分かれる。

1. 物理サーバ/VM の root 奪取:unprivileged ローカルユーザがいるあらゆる Linux ホストで root が取れる。SSH 共用サーバ、踏み台、CI ランナー、開発用 VM はすべて即時対応案件だ。

2. コンテナ脱出の可能性:Canonical は「コンテナデプロイメントではコンテナ脱出を促進し得る」と明言している。ただし発火条件として CAP_NET_ADMIN クラスの権限が必要なため、Kubernetes デフォルトの seccomp プロファイル + non-root + capabilities drop で固めたコンテナでは攻撃面が著しく狭まる。逆に言えば --privileged で雑に運用しているクラスタは丸腰だ。

3. IPsec / AFS 利用環境の運用ジレンマ:推奨ミティゲーションは esp4 / esp6 / rxrpc の モジュールロード禁止 だが、これは StrongSwan などの IPsec VPN や AFS ベースのストレージを直接破壊する。VPN 終端や OpenAFS を本番投入している組織は、CVE-2026-43284 のカーネルパッチ適用と「VPN を一時的に止める」のトレードオフ判断を迫られる。

即時ミティゲーション(IPsec/AFS 不要環境向け):

# 1. モジュール自動ロードを止める
sudo sh -c 'cat > /etc/modprobe.d/dirtyfrag.conf <<EOF
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF'

# 2. 既にロード済みのモジュールをアンロード
sudo rmmod esp4 esp6 rxrpc 2>/dev/null

# 3. 確認
grep -E 'esp[46]|rxrpc' /proc/modules

カーネルパッチ適用が選べる環境では、CVE-2026-43284 の上流コミット f4c50a4034e6 を取り込んだベンダーカーネルへ即アップグレードするのが本筋。RxRPC 側は CVE-2026-43500 のパッチが未提供のため、当面は モジュール無効化が唯一の確実策 という点は要注意である。

まとめ

  • Dirty Frag は ESP (CVE-2026-43284) と RxRPC (CVE-2026-43500) を入口にした 決定論的なページキャッシュ書き込みプリミティブ で、ローカル非特権ユーザから root を奪う。
  • Copy Fail のミティゲーション(algif_aead 無効化)は 完全に無効。攻撃面が別系統のため、追加の esp4 / esp6 / rxrpc 無効化が必須。
  • すでに動く 192 バイト PoC が公開済みで、共用ホスト・CI ランナー・特権コンテナは即対応案件。
  • IPsec / AFS 利用環境は VPN 停止か未パッチ運用かの判断が要る。

Copy Fail から1週間で同型の “ページキャッシュをカーネルが排他所有していない” 系バグが立て続けに 2 件出た事実は、Linux の crypto サブシステムにこの観点での隠れバグがまだ複数眠っている ことを強く示唆する。週次でディストロのカーネル CVE を監視するルーチンを、いま一度仕組み化しておきたい。

今日のその他のニュース

Mojo 1.0 Beta 到達(Hacker News 172pts):Modular の Python スーパーセット言語 Mojo がついに 1.0 Beta に。Python シンタックス互換のまま AI ワークロードを高速化する設計で、本格採用検討の節目になるリリースだ。

ClojureScript が async/await をサポート(HN 247pts):core.async との二重構造を解消できる可能性があり、JavaScript エコシステムとの相互運用性が大きく前進する。Lisp 系の現代的進化として注目。

Google Cloud Fraud Defence は WEI の焼き直し(HN 424pts):Web Environment Integrity への批判で取り下げられた仕組みをエンタープライズ向けに再パッケージしたとの指摘。プラットフォームの権力集中を巡る議論が再燃している。

ソース