最近、Linux カーネルで注目度の高いローカル権限昇格脆弱性が続けて報告されています。Dirty Frag、Copy Fail、Fragnesia です。最終的な効果はいずれも似ています。低権限のローカルユーザーが root に昇格できる可能性があります。
ただし運用対応の観点では、これらを一つの脆弱性として扱うべきではありません。入口となるモジュール、発火経路、緩和策、パッチのタイミングが異なります。より正確には、Linux カーネルの「ページキャッシュ、splice、socket buffer、暗号処理経路」という複雑な境界に共通するリスクを露出させたものです。
この記事ではリスクと対応方針だけを扱い、再現可能な攻撃手順は扱いません。
3 つの脆弱性の概要
Dirty Frag:CVE-2026-43284
Dirty Frag は主に Linux カーネルのネットワーク経路におけるページキャッシュ書き込み問題を指します。公開資料では、xfrm-ESP 側の CVE-2026-43284 と、rxrpc 側の CVE-2026-43500 が一緒に語られることが多いです。
CVE-2026-43284 は、ESP が共有 skb fragment を処理する際のインプレース復号に関係します。重要なのは、攻撃者がディスク上のファイルを直接書き換えるのではなく、カーネルが書くべきでない共有ページへ書き込み、ページキャッシュ内のファイル内容に影響する点です。
運用上覚えておくべきなのは、Dirty Frag が esp4、esp6、rxrpc というカーネルモジュール群とネットワークサブシステム経路に到達することです。IPsec、ESP、RxRPC と関係するため、一時的な緩和策もこれらのモジュールを中心に考えることになります。
Copy Fail:CVE-2026-31431
Copy Fail は Theori / Xint Code が公開した Linux カーネルのローカル権限昇格脆弱性です。入口は IPsec のネットワーク経路ではなく、カーネルのユーザー空間暗号 API である algif_aead / AF_ALG 関連経路です。
公開説明では、2017 年に導入されたインプレース最適化に由来するとされています。特定の状況で、カーネルが期待どおりにデータをコピーせず、ページキャッシュページを writable な宛先経路に入れてしまいます。攻撃者は AF_ALG と splice() を組み合わせ、ページキャッシュに裏付けられたページへ小さな制御書き込みを行えます。
リスクが高い理由は、利用可能性が高く、複数の主要ディストリビューションにまたがって影響するためです。Dirty Frag と違い、Copy Fail の一時的な緩和は algif_aead の制限または無効化、そしてコンテナや CI 環境での AF_ALG socket 作成制限が中心になります。
Fragnesia:CVE-2026-46300
Fragnesia は V12 Security が公開した別の Linux カーネルローカル権限昇格脆弱性で、Dirty Frag と近い攻撃面に属します。Dirty Frag と同じ bug ではありませんが、IPsec ESP / rxrpc 関連モジュールとページキャッシュ書き込み効果を中心にしています。
AlmaLinux はこれを同じコード領域における 3 つ目の local-root 問題として位置付けています。ポイントは、skb_try_coalesce() が socket buffer fragment を結合する際に共有 fragment マーカーを正しく保持しなかったことです。その結果、後続の XFRM ESP-in-TCP 受信経路が外部ページキャッシュページ上でインプレース復号を行う可能性があります。
つまり、Fragnesia は Dirty Frag に近い問題です。どちらも esp4、esp6、rxrpc、skb fragment、ESP 復号経路の周辺にあります。一時的な緩和策も大きく重なります。
共通点:なぜ危険なのか
3 つの共通点は「コード位置が完全に同じ」ということではなく、攻撃結果とリスクモデルが非常に似ていることです。
第一に、いずれもローカル権限昇格です。攻撃者は通常、まず対象マシン上で一般ユーザーとしてコード実行能力を得てから、root への昇格を試みます。単一ユーザーのデスクトップではリモート一発侵害ではありませんが、複数ユーザーサーバー、CI runner、コンテナホスト、共有開発機、SSH を公開している VPS では、低権限入口は珍しくありません。
第二に、いずれもページキャッシュ書き込みに関係します。攻撃者は必ずしもディスク上のファイルを恒久的に書き換えるわけではなく、メモリ上のページキャッシュコピーに影響します。これにより従来のファイル整合性チェックは不十分になり得ます。ディスク hash は正常でも、実行経路が汚染されたページキャッシュ内容を読む可能性があります。
第三に、タイミングに強く依存する競合条件というより、決定的なロジックバグに近いものです。公開資料では、これらの脆弱性は race condition に勝つ必要がないと繰り返し述べられています。防御側は古い経験則で利用成功率を低く見積もるべきではありません。
第四に、コンテナや自動化実行環境のリスクを増幅します。コンテナ内の低権限コード、CI ジョブ、ビルドスクリプト、サードパーティプラグインがホストカーネルの関連インターフェースに到達できると、「ローカル問題」が「プラットフォーム問題」に変わります。
相違点:一つの対策では全部を覆えない
最大の違いは入口となるモジュールです。
Copy Fail の重要な入口は algif_aead / AF_ALG で、カーネルのユーザー空間暗号 API に属します。一時的な防御は algif_aead の無効化または制限、そして seccomp によるコンテナ内の AF_ALG socket 作成ブロックが中心です。
Dirty Frag の重要な入口は xfrm-ESP と rxrpc です。プロトコル処理と socket buffer 処理経路に近く、一時的な防御では esp4、esp6、rxrpc の無効化を検討します。ただし IPsec、VPN、トンネル、関連するネットワーク機能に影響する可能性があります。
Fragnesia の入口も Dirty Frag に近い領域ですが、具体的には skb_try_coalesce() が共有 fragment マーカーを保持しなかったことが問題です。Copy Fail の暗号 API 問題というより、Dirty Frag のリスク面にある別の分岐と見るべきです。
したがって、Copy Fail を処理済みだから Dirty Frag と Fragnesia も覆われる、とは言えません。逆に esp4 / esp6 を無効化したから Copy Fail が消えるわけでもありません。それぞれのパッチ状態と緩和策を別々に確認する必要があります。
影響範囲の判断方法
この種の脆弱性では、ディストリビューション名やカーネルのメジャーバージョンだけで判断しないことが重要です。ディストリビューションは修正をバックポートしますし、クラウドベンダーは独自のカーネルブランチを維持します。企業向けディストリビューションでは追加パッチが入っていることもあります。
より安全な確認順序は次の通りです。
- ディストリビューションのセキュリティアドバイザリとカーネルパッケージ changelog を確認する。
- 現在のカーネルパッケージで対象 CVE が修正済みか確認する。
- クラウドサーバー、コンテナホスト、CI ノードでは、クラウド事業者やプラットフォーム側の公告も確認する。
- 一時的な緩和策では、業務が対象モジュールに依存しているか確認する。
- カーネル更新後は再起動を行い、実際に実行中のカーネルが切り替わったことを確認する。
この手順で最もありがちな落とし穴は「パッケージは更新したが、マシンを再起動していない」ことです。カーネル脆弱性は通常のユーザー空間サービス更新とは違います。新しいパッケージを入れても、再起動するまで古いカーネルが動き続ける可能性があります。
運用上の優先度
最優先で処理すべきマシンは、すべての Linux マシンを均等に並べたものではありません。低権限コード実行が最も起きやすい場所から始めるべきです。
優先度が高い環境は次の通りです。
- 複数ユーザーのログインサーバー
- CI / CD runner
- ビルドマシンと成果物パッケージングマシン
- コンテナホストと Kubernetes ノード
- 共有開発機
- SSH を公開しているクラウドサーバーと VPS
- サードパーティスクリプト、プラグイン、ジョブキューを実行するプラットフォーム
- Web 脆弱性、弱いパスワード、過去の侵害痕跡があるマシン
閉じた単一ユーザー環境で外部コード実行入口がないマシンも、脆弱であればリスクはあります。ただし対応順序は後ろに回せる場合があります。
一時的な緩和策の位置付け
一時的な緩和策はパッチの代替ではありません。すぐに再起動できない、またはディストリビューションのパッケージを待っている間に露出面を下げるためのものです。
Copy Fail では algif_aead と AF_ALG に注目します。業務でカーネル AF_ALG 暗号インターフェースを使っていない場合は、関連モジュールの無効化を評価できます。コンテナ環境では、信頼できないワークロードが該当 socket を自由に作れないよう、まず seccomp ポリシーを確認すべきです。
Dirty Frag と Fragnesia では、esp4、esp6、rxrpc に注目します。システムが IPsec ESP、関連 VPN、トンネル、RxRPC に依存していない場合は一時的な無効化を検討できます。ただし本番環境では不用意に実行しないでください。これらのモジュールは実際のネットワーク業務を支えている可能性があります。
最終的にはカーネル更新に戻る必要があります。一時的な緩和策は攻撃面を減らせますが、システムが完全に安全であることの証明にはなりません。
3 つの脆弱性が示すもの
本当に警戒すべきなのは CVE の数だけではありません。これらの脆弱性はすべて、ゼロコピー、splice、socket buffer、ページキャッシュ、暗号インターフェース、プロトコルスタック最適化といった高複雑度のカーネル経路に集中しています。
これらの経路は大きな性能上の利益をもたらしますが、所有権の境界を保つのが難しくなります。fragment が共有されているか、ページにインプレースで書けるのか、最適化が本当にコピー削減だけなのか、といった点が安全境界そのものになります。
セキュリティチームと運用チームにとって、結論は実務的です。
- ローカル権限昇格は「既存の低権限入口を増幅するもの」として扱う。
- コンテナはカーネル脆弱性に対する自然な隔離境界ではない。
- ファイル整合性チェックはディスク内容だけを見てはいけない。
- CI、ビルドマシン、プラグイン基盤は高優先度資産として扱う。
- カーネルパッチは「インストール済み」と「実行中」の両方を確認する。
まとめ
Dirty Frag、Copy Fail、Fragnesia はいずれも最近の Linux ローカル権限昇格リスクとして優先度の高い事象ですが、一つの脆弱性の別名ではありません。
Copy Fail は algif_aead / AF_ALG 暗号 API 経路を通ります。Dirty Frag は xfrm-ESP と rxrpc 関連経路を通ります。Fragnesia は Dirty Frag に近い攻撃面で、skb fragment マーカー処理の問題により再びページキャッシュ書き込みリスクを引き起こします。
対応として最も堅実なのは、ディストリビューションの公告に従ってカーネルを更新し、再起動することです。すぐに更新できないシステムでは、漏洞の入口に応じて一時的なモジュール無効化や seccomp の強化を評価します。複数テナント、CI、コンテナホスト、共有開発環境を優先してください。
参考資料:
- Theori Copy Fail 説明:https://github.com/theori-io/copy-fail-CVE-2026-31431
- CERT-EU Copy Fail セキュリティアドバイザリ:https://cert.europa.eu/publications/security-advisories/2026-005/
- AlmaLinux Dirty Frag 説明:https://almalinux.org/blog/2026-05-07-dirty-frag/
- AlmaLinux Fragnesia 説明:https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
- V12 Security Fragnesia PoC 説明:https://github.com/v12-security/pocs/tree/main/fragnesia