Linuxサーバー管理者にとって、看過できない情報がTom's Hardwareから報じられました。2017年以降にリリースされたほぼ全てのLinuxディストリビューションに影響する深刻な権限昇格脆弱性「Dirty Frag」が、パッチが用意される前に公開されてしまったとされています。Ubuntu、Arch、RHEL、Fedoraなど主要ディストロが軒並み対象で、現時点で修正パッチは提供されていない状況です。
ローカル実行で即root——「Dirty Frag」の何がヤバいのか
Tom's Hardwareによると、Dirty Fragは現在Linuxサーバー界隈を騒がせている「Copy Fail」と類似のメカニズムを使う脆弱性です。要点を一言でまとめると、「ログインできるローカルユーザーが、小さなプログラムを実行するだけで瞬時にroot権限を奪える」 という、極めて単純かつ強力なバグです。
特徴として、攻撃が特定のシステム条件やタイミングに依存しない、シンプルなロジックバグである点が挙げられています。つまり、対象環境であれば再現性高く悪用できる可能性があるということです。
影響を受けるとされるディストリビューションは広範に及びます。
- Ubuntu（24および26）
- Arch
- RHEL
- OpenSUSE
- CentOS Stream
- Fedora
- Alma
- WSL2（Tom's Hardwareが自ら検証し、rootが取れたと報告）
Tom's Hardwareの同僚はCachyOS（kernel 7.0.3-1-cachyos）および最新のArch環境でもエクスプロイトの発動に成功したと報告しており、メインラインのLinuxカーネル自体にもパッチは見当たらないとしています。
4月30日に報告——なぜパッチがないままエンバーゴが破られたのか
通常、こうした重大な脆弱性は開発元と協調して修正パッチを準備したうえで公開（責任ある開示）されます。しかし今回は、パッチが間に合っていません。
Tom's Hardwareによれば、この脆弱性は4月30日にLinuxカーネルチームに報告されていたものの、「無関係な第三者」がエンバーゴ（情報公開禁止期間）を破ったとされています。同記事は詳細は明らかにされていないとしつつ、「エクスプロイトがすでに悪意のあるアクターによって使われ始めており、それがエンバーゴ破棄を引き起こしたのではないか」という推測を示しています。あくまで同メディアの推測であり、確認された事実ではありません。
技術的には、Copy Failと同様にゼロコピー処理（データコピーを省略してパフォーマンスを上げるカーネルの仕組み）を悪用し、ページキャッシュディスクリプタをスプライスする手法とされています。要するに、本来カーネルが厳重に管理しているメモリ領域に、IPSec関連の処理経路を経由して書き込みを行えてしまう、というのが本質です。 違いは、脆弱なコードが今回はIPSec関連モジュールにある点です。
元の脆弱性は「xfrm-ESP Page Cache Write」で、2017年のカーネルコミットcac2661c53f3で導入され、多くのディストリビューションに残り続けてきたとされています。Ubuntu系ではAppArmorがこの穴を塞いでいるため、PoCは2つ目のエクスプロイト「RxRPC Page-Cache Write」（コミット2dc334f1a63aで追加）を連鎖させるかたちになっているとのことです。
3つのモジュール（esp4・esp6・rxrpc）無効化で当面しのぐ——具体的な緩和コマンド
幸いと言うべきか、Tom's Hardwareは緩和策が比較的容易であり、大半のサーバーの動作に影響しにくいと報告しています。esp4、esp6、rxrpcの3つのカーネルモジュールを無効化するだけで対応可能とされています。
これらはいずれもIPSecネットワーキングに関連するモジュールで、対象マシンがIPSecクライアント／サーバーとして運用されていない限り、使われていない可能性が高いとのことです。
Tom's Hardwareが紹介している無効化コマンドは以下の通りです。
sh -c "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; true"
ただし、IPSecを業務で利用している環境ではこの緩和策は適用できないため、別途運用面での対策（アクセス制御の強化、ローカルログイン可能なユーザーの制限など）の検討が必要になります。
なお、自環境が影響を受けるかどうかの検証用PoCも、V4bel/dirtyfragというGitHubリポジトリで公開されているとTom's Hardwareは伝えています。検証は必ず管理下のテスト環境で行うべきものです。検証用のコマンド例は以下の通りです。
git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
数値で押さえるDirty Fragの要点
ここまでの情報を、Tom's Hardwareが伝える具体的な数値・識別子で整理しておきます。
- 影響開始時期: 2017年以降のほぼ全Linuxディストロ（元コミット導入年）
- 元脆弱性のコミットID:
cac2661c53f3（xfrm-ESP Page Cache Write、2017年導入） - 連鎖に使われる2つ目のコミットID:
2dc334f1a63a（RxRPC Page-Cache Write） - 報告日: 4月30日（Linuxカーネルチームへの報告）
- 再現確認されたカーネル例: CachyOS
kernel 7.0.3-1-cachyos - 対象Ubuntuバージョン: 24および26
- 無効化すべきモジュール数: 3個（
esp4、esp6、rxrpc） - 現時点で利用可能なパッチ数: 0（メインラインカーネル含む）
「2017年導入のコミット1つ」と「Ubuntu向けにAppArmorを回避する2つ目のコミット」という、合計2つの脆弱コードを連鎖させる構成になっている点も覚えておきたいポイントです。
共有サーバー運用者は今すぐ動くべき局面
この情報は現時点ではTom's Hardwareによる報道ベースであり、エンバーゴ破棄に関する経緯（誰がなぜ破ったのか、本当に悪用が始まっているのか）は確認されていません。一方で、複数環境（Ubuntu 24/26、Arch、CachyOS kernel 7.0.3-1-cachyos、WSL2など）での再現がメディアにより報告されている点は重く受け止めるべきです。
サーバー運用者にとっては、即座に様子見ではなく緩和策を検討すべきタイプの情報です。特にマルチユーザーが同一マシンにログインできる環境（共有開発サーバー、教育機関の計算機、Webホスティング等）では、ローカル権限昇格の影響が大きくなります。
現時点では「メインラインカーネルにもパッチが見当たらない」とTom's Hardwareは報告しているため、公式パッチが出るまでは上記3モジュール無効化による緩和策と、ローカルアクセス権の見直しを並行して進めるのが妥当な判断と言えそうです。続報とディストリビューション各社からの公式アナウンスを注視しましょう。
Q&A
Q. 自分のLinuxサーバーは影響を受けますか？
Tom's Hardwareによれば、2017年以降にリリースされたUbuntu（24/26）、Arch、RHEL、OpenSUSE、CentOS Stream、Fedora、Alma、さらにWSL2やCachyOS（kernel 7.0.3-1-cachyos）でも影響が確認されているとされています。元の脆弱性「xfrm-ESP Page Cache Write」は2017年のカーネルコミットcac2661c53f3で導入されたとされ、広範なディストリビューションが対象とみられるため、対象外と決めつけずに緩和策の適用を検討するのが安全です。
Q. パッチはいつ出るのでしょうか？ 本記事執筆時点でTom's Hardwareは「パッチは存在しない」と報じており、メインラインのLinuxカーネルにも修正は見当たらないとしています。脆弱性は4月30日にカーネルチームへ報告されていたもののエンバーゴが破られたかたちで情報が出てしまった、と同メディアは伝えています。公式アナウンスと更新を注視してください。
Q. 緩和策を適用すると業務に影響はありますか？
無効化対象のesp4、esp6、rxrpcはいずれもIPSec関連モジュールで、IPSec VPNを運用していない環境では影響は出にくいとTom's Hardwareは説明しています。ただし、IPSecクライアント／サーバーとして使っている環境では別途検討が必要です。
