2026年4月末、Linuxコミュニティを揺るがした「Copy Fail」脆弱性からわずか一週間後、同じ研究者Hyunwoo Kimが二つ目の重大なLPEを公開した。名称は「Dirty Frag」。Linuxカーネル上で権限のないローカルユーザーがroot権限を即座に取得できるバグで、影響を受けるのはDebian、Ubuntu、Fedora、RHEL系をはじめとする全主要ディストリビューションである。

問題が複雑なのは、その公開の経緯にある。Kimは5月12日の協調開示を目指してlinux-distrosのセキュリティリストとエンバーゴ交渉を進めていた。しかし、第三者が先行して情報を公開したことでエンバーゴは破棄された。Kimはoss-securityのメンテナーへ相談した上でその要請に従い、ディストリビューションへのパッチが間に合わない状態のまま2026年5月7日に完全な技術文書とエクスプロイトコードを公開した。現時点でこのバグにはCVE識別子が割り当てられておらず、Red HatやCanonicalを含む主要ディストリビューションからの公式パッチも存在しない。

エンバーゴ破棄の原因については、netdevツリーに投入された修正コミットを遡る形で第三者が脆弱性を再発見した可能性が指摘されている。LLMを用いてパッチのdiffからエクスプロイトを逆算する手法が現実的な脅威になりつつあることも、コミュニティ内で議論されている。エンバーゴが有効に機能するかどうか、そのモデル自体が問い直されている状況である。

AD

IPsec受信パスの欠陥：脆弱性の技術的構造

Dirty Fragの根本原因は、esp4・esp6・rxrpcの受信高速パスにある。これらのモジュールは、ソケットバッファがsplice(2)・sendfile(2)・MSG_SPLICE_PAGES経由で渡されたページフラグメントを保持している場合、そのページをカーネルが「私的に所有している」と誤って判断してしまう。

通常、暗号化データを平文に復号する処理は、カーネルが単独で所有するページ上でのみ行われなければならない。しかしspliceによってパイプ経由でソケットバッファに取り込まれたページは、非特権プロセスのユーザー空間からも同じ物理メモリを参照できる状態にある。Dirty Fragはこの条件を悪用し、IPsec ESPまたはrxrpcの復号処理を引き金に、そのページを書き換える。

具体的には、2つの別々の脆弱性を連鎖させる構造になっている。一方はIPv4/IPv6のESP（Encapsulating Security Payload）処理経路、もう一方はAFSなどで使われるrxkad認証をもつrxrpcプロトコル経路である。前者ではxfrmネットワーク名前空間とspliceを組み合わせて/usr/bin/suのページキャッシュに直接シェルELFを書き込む手法が使われる。後者ではAF_RXRPCソケットによるrxkad認証ハンドシェイクを偽装し、pcbc(fcrypt)復号処理を介して/etc/passwdのページキャッシュを書き換え、uid=0のエントリを作成する。いずれもunshare(CLONE_NEWUSER | CLONE_NEWNET)による非特権ユーザー名前空間の作成を前提とするため、ユーザー名前空間が無効化された環境では動作しない。

Kimが公開したエクスプロイトは192バイトのミニマルなx86_64 ELFを使い、setgid(0)・setuid(0)・setgroups(0, NULL)の後にexecve("/bin/sh")を実行する。コード量は少ないが、再現性が高く安定した権限昇格を実現している。esp4/esp6経路は/usr/bin/suを直接書き換えてシェルELFに置換し、rxrpc経路は/etc/passwdを改ざんしてuid=0エントリを挿入する——経路は異なるが、どちらも最終的に同一のrootシェルへ到達する。

パッチ不在の今、何をすべきか：暫定緩和策の詳細

正式なカーネルパッチが各ディストリビューションに展開されるまでの間、最も即効性の高い対策は脆弱なカーネルモジュール3本のロードを禁止することである。多くのシステムでIPsec ESPやAFS/rxrpcは一般的な業務ワークロードでは使用されないため、この措置はほとんどの環境で安全に実施できる。

plaintext
sudo 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"

このコマンドは/etc/modprobe.d/dirtyfrag.confに3モジュールのロードを恒久的に禁止する設定を書き込み、現在ロードされていれば即座にアンロードする。rmmodはモジュールが存在しない場合でもエラーを抑制するため、全サポート対象リリースでそのまま実行できる。設定を元に戻すには/etc/modprobe.d/dirtyfrag.confを削除するだけでよい。

IPsec ESPやAFSを実際に使用している環境でこの緩和策を適用すると、通信が切断される。そうした環境では、パッチ済みカーネルへの更新とリブートを優先するべきである。

マルチテナントのクラウドインスタンスやコンテナビルドファーム、CI/CDランナーなど複数ユーザーが同一カーネルを共有する環境では、このバグの危険度は格段に上がる。非特権ユーザーが一人でもシェルアクセスを持てばroot奪取が成立するため、緩和策の適用はパッチ配布を待たず即刻実施するべきである。一方、AFSやrxrpcを業務で利用するHPC環境ではモジュール削除が業務停止につながるため、テスト済みカーネルへの移行計画を先に立てた上で実施順序を調整する必要がある。

エクスプロイトは/etc/passwdや/usr/bin/suといった機密ファイルのページキャッシュを汚染する。緩和策を適用する前に攻撃を受けた恐れがある場合は、以下のコマンドでページキャッシュを破棄しておくべきである。

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

なお、AlmaLinuxはkernel-modules-partnerサブパッケージに含まれるrxrpc.koがデフォルト構成では存在しないため、標準インストール環境でrxrpc経由のエクスプロイトは動作しない。ただしkernel-modules-partnerパッケージをインストールしている場合は、そのパッケージ自体を削除するのが最善である。

AD

AlmaLinuxが先行パッチをテストリポジトリへ投入

ディストリビューションの中で最初に行動したのはAlmaLinuxである。Red HatやCentOS Streamからの上流パッチを待たず、アップストリームのESP修正（mainlineコミットf4c50a4034e6）を各サポート対象ブランチにバックポートし、テストリポジトリへの投入をALESCo（AlmaLinux Engineering Steering Committee）が承認した。

AlmaLinux 8はkernel-4.18.0-553.123.2.el8_10、AlmaLinux 9はkernel-5.14.0-611.54.3.el9_7、AlmaLinux 10はkernel-6.12.0-124.55.2.el10_1以降でそれぞれパッチが当たっている。AlmaLinux Kitten 10については次回の通常カーネルビルドで対応済みとなるため、テストリポジトリの有効化は不要である。

テストリポジトリからのアップデートはsudo dnf install -y almalinux-release-testingでリポジトリを有効化した後、sudo dnf update 'kernel*' --enablerepo=almalinux-testingで実行できる。コミュニティによる検証が完了次第、本番リポジトリへの移行が予告されている。

エンバーゴの限界：LLMが変えるセキュリティ開示の地形

Dirty Fragの公開をめぐる経緯は、脆弱性の協調開示（CVD: Coordinated Vulnerability Disclosure）モデルが現代の脅威環境に適合できていないことを端的に示している。従来のエンバーゴモデルは、パッチコードや技術情報を限られた関係者のみに制限することで、開示までの間にディストリビューターがパッチを準備する時間を確保するものだった。

しかし近年、LLMを活用して公開されたカーネルパッチのdiffをリバースエンジニアリングし、数時間以内にエクスプロイトを生成する手法が現実的な能力として確立しつつある。netdevツリーへのコミットはエンバーゴ対象の情報ではないが、そこから脆弱性の存在と技術的詳細を逆算することは、今や高度なスキルを持たない攻撃者にも可能になりつつある。Dirty Fragが「並行発見（parallel discovery）」の可能性を持つ経緯で早期公開に至ったことは、この新しい脅威モデルを示す最新の事例である。

エンバーゴが機能する前提条件——「秘匿が攻撃者への情報到達を防ぐ」——が崩れつつある状況では、開示プロセスそのものの再設計が求められる。ディストリビューション横断の24時間パッチビルドパイプラインや、カーネルモジュールの動的ロード制御をOSレベルで強制する仕組みの整備など、「エンバーゴが破棄されても被害を最小化できるアーキテクチャ」を前提にした設計へのシフトが、次のLinuxセキュリティコミュニティの課題となる。