マストウ警報：Linux の重大な権限昇格脆弱性、3つのモジュールを停止して緊急に緩和
慢霧の最高情報セキュリティ責任者が 23pds を 5 月 8 日に開示し、Linux システムに Dirty Frag という重大な権限昇格の脆弱性が存在することが判明した。完全な詳細と利用コードはすでに公開されており、あらゆるローカルの低権限ユーザーが、特定のシステム条件を必要とせずに、影響を受けたシステムの root 管理者権限を直接取得できる。緊急の緩和策は、esp4、esp6、rxrpc の 3 つのモジュールを無効化することだ。
Dirty Frag がこれほど危険な理由：ロジック脆弱性、高成功率、パッチなし
Dirty Frag は競合条件に依存する不安定な攻撃ではなく、確定的なロジック脆弱性に分類されるため、成功率が非常に高く、安定して再現できる。攻撃者は小さなプログラムを実行するだけで、すぐに標的システムの root 権限を取得でき、全過程でコアがクラッシュすることもないため、通常の監視では検知されにくい。
脆弱性は 4 月 30 日にセキュリティ研究者が Linux カーネルチームへ提出されたが、修正作業が完了する前に「無関の第三者」が詳細情報と利用コードを先行して漏えいしたことで、安全上の禁令が解除を余儀なくされた。セキュリティコミュニティでは、このことは悪意のある攻撃者がすでにこの脆弱性を積極的に悪用している可能性があることを意味する、と広く見られている。
技術原理の観点では、Dirty Frag は、現在 Linux サーバー領域で広く被害を生んでいる Copy Fail 脆弱性のメカニズムと類似しており、いずれもページキャッシュ記述子をゼロコピー操作に挿入することで攻撃を成立させる。根本的な脆弱性「xfrm-ESP Page-Cache Write」は、2017 年のカーネルコミット cac2661c53f3 により導入された。Ubuntu の AppArmor が当該脆弱性を修正したため、PoC は 2 つ目の脆弱性「RxRPC Page-Cache Write」（コミット 2dc334f1a63a）を連結し、Ubuntu システム上でも攻撃が同様に有効であることを確実にしている。
影響範囲：確認済みの主要 Linux ディストリビューション一覧
確認済みの影響を受ける Linux ディストリビューション（の一部）：
· Ubuntu 24 および Ubuntu 26（AppArmor を含む、2 つ目の脆弱性によりバイパス）
· Arch Linux（更新済みのバージョンでも影響を受けることが確認済み）
· RHEL（Red Hat Enterprise Linux）
· OpenSUSE
· CentOS Stream
· Fedora
· AlmaLinux
· CachyOS（カーネルバージョン 7.0.3-1-cachyos がトリガーすることが確認済み）
· WSL2（Windows Subsystem for Linux）も影響を受けることが確認済み
緊急緩和策：3 つのモジュールを無効化する具体的なコマンド
公式なパッチが公開されるまで、最も有効な緩和策は esp4、esp6、rxrpc の 3 つのモジュールを無効化することだ。これら 3 つのモジュールはいずれも IPSec ネットワーク機能に関連しているため、サーバー自体が IPSec クライアントまたはサーバーでない限り、無効化しても通常の業務への影響はほぼない。
以下のコマンドを実行すれば、モジュールの無効化が完了する：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”
実行後は、各 Linux ディストリビューションのセキュリティ公告を注意深く追跡し、公式パッチが正式に公開されたら直ちにシステム更新を展開してほしい。
よくある質問
Dirty Frag 脆弱性には現在、公式パッチがあるのか？
現時点では、公式はいかなるパッチも公開していない。Linux のメインラインカーネルでも修正コミットは確認されていない。これは、安全上の禁令がパッチ準備完了前に先行して破られたためであり、修復作業が完了する前の段階で脆弱性の詳細が公開されてしまった。システム管理者は、Linux ディストリビューションのセキュリティ公告を密に追跡し、パッチ公開後すぐに展開してほしい。
esp4、esp6、rxrpc のモジュールを無効化すると、サーバーの通常業務に影響するか？
この 3 つのモジュールは主に IPSec プロトコルに関連している。サーバー自体が IPSec クライアントまたはサーバー（つまりネットワーク層での暗号化通信に使用される場合）でない限り、Web サービス、データベース、暗号化ノードなどの一般的な業務への影響はほぼなく、現時点で最も安全かつ影響が最小の緊急緩和策となっている。
なぜ今回の脆弱性は、パッチがない状態で公開されたのか？
業界の慣例は「責任ある開示」だ。すなわち、安全研究者がベンダーに脆弱性を提出した後、通常はパッチが完成してから詳細を公開する。今回の脆弱性は 4 月 30 日に提出されたが、「無関の第三者」が詳細情報を先行して漏えいし、禁令を破ってしまった。安全研究者は、悪意のある攻撃者がすでにこの脆弱性を積極的に悪用していた可能性があると推測しており、これが最終的に禁令が解除された引き金になったのだという。