脆弱性 on KnightLiブログ

Dirty Frag、Copy Fail、Fragnesia：最近の Linux ローカル権限昇格脆弱性 3 件の比較

Fri, 15 May 2026 13:24:04 +0800

最近、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

Fragnesia (CVE-2026-46300)：Linux カーネルのローカル権限昇格脆弱性の影響と緩和策

Fri, 15 May 2026 13:18:01 +0800

Linux カーネルで、Dirty Frag と同じ系統の攻撃面に関係するローカル権限昇格脆弱性が新たに報告されました。Fragnesia (CVE-2026-46300) です。

V12 Security の公開情報によると、Fragnesia は Linux のローカル権限昇格脆弱性です。攻撃者はホスト上で高権限を持っている必要はありません。ローカルでコードを実行できれば、カーネルの XFRM ESP-in-TCP サブシステムのロジック欠陥を利用し、読み取り専用ファイルのページキャッシュ内容をバイト単位で書き換え、最終的に root shell を得られる可能性があります。

原資料：

V12 Security PoC 説明：https://github.com/v12-security/pocs/blob/main/fragnesia/README.md

この記事では再現可能な攻撃手順は扱わず、運用側が把握すべきリスクと対応方針に絞ります。

Dirty Frag との関係

V12 Security は Fragnesia を Dirty Frag 脆弱性クラスに分類しています。Dirty Frag と同一の bug ではありませんが、Linux カーネルの XFRM ESP-in-TCP という同じ攻撃面にある別の問題です。

XFRM は Linux カーネルで IPsec を処理するためのフレームワークです。ESP-in-TCP は ESP 暗号化トラフィックを TCP 上で運ぶ仕組みに関係します。Fragnesia の問題は、共有ページフラグメントと socket buffer の結合処理にあります。特定の状況で、カーネルが fragment がまだ共有状態であることを見失い、制御可能な書き込み余地が生まれます。

この種の問題は Dirty Pipe / Dirty Frag のようなページキャッシュ書き込み脆弱性を想起させます。具体的なコードは同一ではありませんが、攻撃効果が読み取り専用ファイルのページキャッシュ上のコピーに到達する点が共通しています。

なぜ危険なのか

Fragnesia が危険な理由は主に 3 つあります。

第一に、これはローカル権限昇格です。攻撃者が通常ユーザーとしてコードを実行できるだけで、root に昇格できる可能性があります。複数ユーザーのサーバー、コンテナホスト、CI runner、共有開発機、VPS、Shell を公開している環境では、通常のデスクトップよりも深刻です。

第二に、従来型の競合条件に依存しません。V12 の説明では、ESP-in-TCP の処理フローを構成し、すでに socket buffer に splice されたファイルページ上で暗号化ストリームを処理させることで、ページキャッシュ内容にバイト単位の影響を与える経路が示されています。これは単なる理論上の可能性ではなく、安定した利用経路が検証されていることを意味します。

第三に、変更されるのはディスク上のファイルではなくページキャッシュです。公開説明の例では /usr/bin/su が対象になっています。成功後もディスク上のファイルは恒久的には書き換えられず、変更はメモリ上のページキャッシュに存在します。ディスクファイルの hash や整合性だけを確認する巡回チェックでは異常を見逃す可能性があります。

管理者にとって厄介なのはここです。ファイルは変わっていないように見えても、汚染されたページキャッシュ上の対象バイナリを実行すると権限昇格につながる可能性があります。

既知の影響範囲

V12 Security の説明では、Dirty Frag の影響を受け、2026 年 5 月 13 日の関連パッチが適用されていないカーネルは Fragnesia の影響も受けるとされています。公開検証環境には Ubuntu 22.04、Ubuntu 24.04、6.8.0-111-generic などのカーネルが含まれます。

注意点は 2 つあります。

第一に、ディストリビューションのメジャーバージョンだけで判断しないことです。Ubuntu 22.04 / 24.04 が影響を受けるかどうかは、ディストリビューション名ではなく実際のカーネルパッチ状態で決まります。

第二に、デフォルトの AppArmor 制限だけに頼らないことです。Ubuntu の非特権ユーザー名前空間に対する AppArmor 制限はハードルを上げますが、公開情報ではそれは追加の回避対象であり、脆弱性本体の根本対策ではありません。

信頼できる判断方法は、各ディストリビューションのセキュリティアドバイザリとカーネルパッケージ更新を確認することです。

一時的な緩和策

すぐにカーネルを更新できない場合は、まず関連プロトコルモジュールに依存しているかを確認します。

V12 が示す緩和方向は Dirty Frag と同じです。システムが IPsec ESP や RxRPC に依存していない場合、esp4、esp6、rxrpc などのモジュール無効化を検討できます。ただしネットワーク機能に影響するため、本番環境で不用意に実行すべきではありません。IPsec、VPN、トンネル、関連するカーネル機能を業務で使っているか確認が必要です。

より安全な対応順序は次の通りです。

ディストリビューションがカーネルのセキュリティ更新を公開しているか確認する。
まずカーネルパッチをインストールし、再起動を計画する。
すぐに更新できない場合のみ、一時的なモジュール無効化を評価する。
複数ユーザーシステムと CI / ビルド環境を優先する。
不要なローカルアカウント、Shell、コンテナ脱出面、低権限実行入口を確認する。

モジュール無効化を最終修復とみなすべきではありません。これは露出面を一時的に下げる手段です。

すでに悪用された疑いがある場合

Fragnesia の特徴の一つはページキャッシュ汚染です。V12 は、悪用後に対象ファイルのページキャッシュ上のコピーが注入内容を含み、ページが追い出されるかシステムが再起動されるまで、後続の実行で異常な挙動を起こし得ると説明しています。

悪用が疑われる場合は、少なくとも次を実施します。

できるだけ早くログと監査記録を保全する。
最近の異常なローカルログイン、低権限ユーザー活動、不審なプロセス、root shell の痕跡を確認する。
関連するページキャッシュをクリアするか、直接再起動する。
修正済みカーネルへ更新する。
重要バイナリの整合性を確認する。ただしディスク hash のみに依存しない。
露出した可能性のある認証情報と鍵をローテーションする。

本番サーバーであれば、単なる通常のパッチ適用ではなく、潜在的なローカル権限昇格インシデントとして扱う方が安全です。

優先して確認すべきマシン

この種の脆弱性では、すべての Linux マシンを同じ優先度で扱うのではなく、攻撃者が低権限コード実行を得やすい場所から見るべきです。

優先度が高い環境は次の通りです。

複数ユーザーのログインサーバー
CI / CD runner
ビルドマシン
共有開発機
コンテナホスト
VPS とクラウドサーバー
SSH を公開しているエッジノード
サードパーティ製スクリプトやプラグインを実行するプラットフォーム

閉じた単一ユーザー環境で外部コード実行入口がないマシンも、脆弱であれば影響はあります。ただし緊急度は相対的に下げられます。

まとめ

Fragnesia が注目に値するのは名前が新しいからではありません。Linux のローカル権限昇格問題を、ページキャッシュとカーネルネットワークサブシステムの複雑な境界へ再び引き戻したからです。

管理者にとって重要なのは、攻撃手順を研究することではなく、カーネルのパッチ状態を確認し、ESP / RxRPC への依存を評価し、露出度の高いマシンを優先して更新し、「ディスクファイルが変わっていない」ことが「システムが影響を受けていない」ことを意味しないと理解することです。

影響を受けるシステムでは、最終的な答えはディストリビューションが提供するカーネル更新をできるだけ早く適用することです。一時的なモジュール無効化は移行措置であり、パッチの代替ではありません。