Linuxカーネル on KnightLiブログ

AI脆弱性発見の時代が来た：Copy Fail、Dirty Frag、Fragnesia、ssh-keysign-pwnはなぜ集中発生したのか

Thu, 21 May 2026 09:30:01 +0800

最近、Linuxカーネル関連の脆弱性が相次いでいます。Copy Fail、Dirty Frag、Fragnesia、ssh-keysign-pwnが次々にセキュリティ界隈で議論されました。ローカル権限昇格につながるものもあれば、高感度ファイルを漏えいさせるもの、コンテナホストやマルチテナント環境に影響するものもあります。多くの人の第一印象は、「Linuxはなぜ急にここまで危なくなったのか」というものです。

より正確に言えば、Linuxが突然悪くなったわけではありません。長く隠れていた問題が、より速く、より体系的に掘り出されるようになったのです。

今回の波で本当に注目すべきなのは、いくつかのCVE修正だけではありません。脆弱性の発見方法が変わったことです。以前は、少数のトップ研究者が長い時間をかけて、サブシステムをまたぐロジックバグをつなぎ合わせる必要がありました。今では、AI支援監査、自動静的解析、fuzzing、セキュリティ研究プラットフォームがその作業を大きく増幅しています。脆弱性が一夜にして増えたのではなく、発見、再現、拡散の速度が上がったのです。

これらの脆弱性に共通すること

まず、最近の事例を並べて見ます。

脆弱性	主な影響	重要な特徴	リスクの焦点
Copy Fail / CVE-2026-31431	ローカル権限昇格	Linux crypto / AF_ALG関連経路、page cache書き込み問題を含む	一般ユーザーからrootへ。特にコンテナ環境で敏感
Dirty Frag / CVE-2026-43284、CVE-2026-43500	ローカル権限昇格	XFRM/ESP、RxRPCなどの経路におけるpage cache書き込みプリミティブ	チェーン利用可能。ホストとコンテナ境界に影響
Fragnesia / CVE-2026-46300	ローカル権限昇格	XFRM ESP-in-TCPサブシステムのロジック問題	Dirty Fragに近い攻撃面
ssh-keysign-pwn / CVE-2026-46333	ローカルの機密情報漏えいと権限昇格リスク	Linux kernel `__ptrace_may_access()` のロジック欠陥	SSHホスト鍵、`/etc/shadow`などの機密ファイルリスク

これらは完全に同じ脆弱性ではありませんが、いくつかの共通点があります。

従来型のリモートRCEではなく、ローカル権限昇格またはローカル機密情報漏えいである。
攻撃者はまず通常のshell、コンテナ内のコマンド実行、CIタスク権限、低権限アカウントなど、何らかのローカル実行能力を持つ必要がある。
多くのリスクはカーネル境界に集中している。page cache、暗号/ネットワークサブシステム、ptrace権限判定、コンテナ共有カーネルなど。
コンテナは強い安全境界ではなく、ホストカーネルが共通基盤であるため、現代のクラウドネイティブ環境では影響範囲が拡大する。

したがって問題は「パッチがあるか」だけではありません。より深い問題は、なぜこのような低レベルで隠れた、長く潜伏していた問題が短期間に集中して現れたのかです。

第一の理由：多くの脆弱性は新しく書かれたものではなく歴史的負債

脆弱性の公開日を見ると、そのバグが最近のバージョンで入ったものだと思いがちです。しかし実際には、そうでないことが多いです。

Copy Failのような問題の重要点は、脆弱性が何年も潜伏し得ることです。正しい呼び出し経路、権限境界、メモリセマンティクスを誰かがつなげて初めて見つかります。公開情報では、Copy Failは2017年前後のカーネル最適化の歴史と関係があるとされています。Dirty FragやFragnesiaも、ネットワーク、暗号、page cacheといった深い交差経路を指しています。

この種の脆弱性の怖さは、ある一行のコードが明らかに危険に見えることではありません。複数の前提がたまたま重なることにあります。

あるサブシステムが性能のためにインプレース処理を行う。
あるインターフェースが非特権ユーザーにカーネル機能へ到達させる。
ある経路が読み取り専用ファイルページ、page cache、ネットワーク断片、暗号バッファをつなぐ。
ある暗黙の制約が型システム、assert、ドキュメントに書かれていない。
最終的に、一般ユーザーが本来影響できないカーネル状態に影響する経路になる。

これは通常のコードレビューが最も得意とする問題ではありません。あるレビュー担当者はcryptoサブシステムを理解し、別の人はネットワークサブシステムを理解し、第三者はメモリ管理を理解しているかもしれません。しかし脆弱性はその交差点に隠れています。

第二の理由：Linuxカーネルの複雑性は人工レビューの限界を超えている

Linuxの強みは、オープンで汎用的で、幅広いハードウェアに対応し、エコシステムが強いことです。しかしそれらの強みは代償も伴います。

現代のLinuxカーネルは単なる「小さなカーネル」ではありません。スケジューリング、メモリ管理、ファイルシステム、ネットワークプロトコルスタック、暗号フレームワーク、ドライバ、仮想化、コンテナ関連機構、eBPF、LSM、セキュリティモジュール、ハードウェアプラットフォーム対応など大量のサブシステムを含みます。各サブシステムには歴史、メンテナ、性能目標、互換性の負債があります。

問題は、脆弱性が単一モジュール内ではなく、モジュール同士の交点に存在しがちなことです。

splice() はファイルページとpipeをつなぐ。
AF_ALGはユーザー空間とカーネルcrypto APIをつなぐ。
XFRM/ESPはネットワークパケット、暗号、メモリページをつなぐ。
RxRPCやESP-in-TCPのような経路はネットワークスタックをさらに複雑にする。
コンテナは低権限ローカル実行をより一般的な現実の前提にする。

エンジニアリングの観点では、Linuxカーネルはもはや「十分な目があれば全部見られる」規模ではありません。オープンソースは問題の修正と検証を容易にしますが、すべての隅が継続的かつ安全にレビューされることを意味しません。サブシステム横断の脆弱性を本当に理解できる人は少なく、そうした脆弱性ほど大きな影響を生みやすいのです。

第三の理由：性能最適化は安全境界を薄くしがち

今回の脆弱性群では、性能のためにコピーを減らし、バッファを再利用し、データをインプレース処理するというテーマが繰り返し出てきます。

この種の最適化は非常に合理的です。カーネルはインフラであり、少しの性能低下がクラウド事業者、データベース、ネットワーク、ストレージ、コンテナ基盤に影響します。コピーを一回減らす、暗号化/復号を速くする、メモリ割り当てを減らすことは、実運用で価値があります。

しかし安全上の代償も明確です。「読み取り専用データ」「共有ページ」「ユーザー制御入力」「カーネルバッファ」「暗号出力」の境界が薄くなると、あるサブシステムが入出力契約を誤解しただけで、不正な書き込みや読み取りにつながります。

つまり、性能最適化自体が悪いわけではありません。しかし、より壊れやすい組み合わせを作ります。

インプレース暗号化/復号はコピーを減らすが、入力/出力バッファの正しい隔離により強く依存する。
page cacheはファイルアクセス性能を高めるが、攻撃面にもなり得る。
ゼロコピーはスループットを高めるが、異なるサブシステムが同じメモリオブジェクトを共有する。
コンテナはデプロイ効率を高めるが、共有カーネルによりローカルLPEの爆発半径を大きくする。

安全境界は「みんながミスしないことを覚えている」だけでは維持できません。型、権限チェック、不変制約、テスト、fuzzing、継続監査によって強制される必要があります。そうでなければ、性能最適化と暗黙の仮定が増えるほど、脆弱性はいずれ掘り出されます。

第四の理由：コンテナがローカル脆弱性の価値を高めた

以前は「ローカル権限昇格」は、攻撃者がすでにローカルアクセスを必要とするため、リモート脆弱性より低リスクに見られがちでした。クラウドネイティブ時代はこの判断を変えました。

今日の「ローカル実行」の入口は多くあります。

Webアプリケーションが通常のshellを取られる。
CI/CDタスクが信頼できないコードを実行する。
コンテナ内でユーザーアップロードのタスクが走る。
マルチテナント平台がnotebook、プラグイン、スクリプト、ビルドタスクの実行を許す。
AIコード実行環境、サンドボックス、オンライン評価平台が増えている。

攻撃者がコンテナ内で実行能力を得ると、カーネルLPEはもはや「そのマシンだけの小問題」ではありません。コンテナはホストカーネルを共有するため、カーネル脆弱性はコンテナ境界を越え、ホストや他のテナントに影響し得ます。

これが、Copy FailやDirty Fragのような脆弱性がクラウド、セキュリティ、コンテナチームから強く注目される理由です。それらは「低権限ローカルコード実行」を「ホスト級リスク」に引き上げる可能性を高めます。

AIの影響：脆弱性発見コストが下がった

今回の波で最も時代性がある部分は、AI支援の脆弱性発見です。

Copy Failの公開資料では、TheoriのXint Codeが発見過程に関与したことが言及されています。具体的なツール能力がどうであれ、これは一つの傾向を示しています。AIは必ずしも脆弱性を「無から発明する」わけではありませんが、研究者が検索経路を短縮するのを非常に得意とします。

AIが脆弱性研究に与える影響は主に次の点にあります。

見慣れないコードをより速く読む
カーネルサブシステムのコード量は非常に大きく、研究者がすべての経路を手で読むことはできません。AIは関数、呼び出しチェーン、入出力関係、怪しいパターンを素早く要約できます。
モジュール横断の接続を見つけやすくする
多くの脆弱性は「ユーザー空間入口 -> ネットワークスタック -> 暗号フレームワーク -> メモリページ -> ファイルキャッシュ」のような連鎖に隠れています。AIはファイル、ディレクトリ、サブシステムをまたぐ経路整理を補助できます。
監査仮説を生成しやすくする
たとえば「どの経路がユーザー制御データをpage cacheに書くのか」「どのAPIが非特権ユーザーにcryptoサブシステムへ到達させるのか」「どの関数が入力と出力バッファは重ならないと仮定しているのか」。以前は経験で少しずつ考える問題でしたが、今はより体系的に列挙できます。
再現可能な例へ変えやすくする
AIはカーネル研究者の判断を代替できませんが、検証コード、PoCの整理、誤った経路の説明、テストケース生成を助けられます。

結果として、脆弱性発見の単位コストが下がります。

以前なら、高品質なカーネル脆弱性を発見するにはトップ研究者が長い時間を使う必要がありました。今は、システムを理解する人がAIツールを使えば、疑わしい経路をより速く絞り込めます。脆弱性供給の上限が上がり、集中公開が起きやすくなっています。

ただしAIだけが原因ではない

もう一つの極端、すべてをAIのせいにすることも避けるべきです。

AIは加速器であり、根本原因ではありません。根本原因は依然として次の通りです。

歴史的コードの長期蓄積。
性能最適化における暗黙契約が強制されていない。
サブシステム横断の複雑性が高すぎる。
デフォルトで露出するカーネル機能が多すぎる。
セキュリティテストがすべての組み合わせ経路を覆っていない。
コンテナ、マルチテナント、自動実行環境がローカル脆弱性の価値を高めた。

これらの基盤条件がなければ、どれほど強いAIでもこれほど多くの高影響脆弱性を掘り出すことはできません。逆に、これらの条件が存在する限り、AIが成熟するほど、脆弱性はより体系的に見つかりやすくなります。

防御側にとっての意味

運用、セキュリティ、プラットフォームチームにとって、今回の波には直接的な示唆があります。

第一に、「ローカル権限昇格」を低優先度として扱わないこと。
環境にコンテナ、CI、オンライン実行、プラグイン、notebook、マルチテナントタスクがあるなら、ローカル権限昇格はホストリスクになり得ます。

第二に、カーネルパッチのペースを上げること。
重要なホスト、Kubernetesノード、CI Runner、AIサンドボックス、仮想化ホストを古いカーネルに長期間置くべきではありません。カーネル更新、再起動ウィンドウ、live patch、段階的ロールバックの明確なプロセスが必要です。

第三に、不要なカーネル攻撃面を減らすこと。
不要なプロトコル、モジュール、ユーザー名前空間、特殊socket、デバッグインターフェースは、業務要件に応じて絞るべきです。デフォルトで有効であることは、デフォルトで露出すべきことを意味しません。

第四に、コンテナセキュリティではカーネルが破られる可能性を前提にすること。
コンテナ内でnon-rootを使い、capabilitiesを最小化し、seccomp、AppArmor/SELinux、読み取り専用ファイルシステム、機密マウントの隔離を使うことは今も重要です。すべてのカーネル脆弱性を止められるとは限りませんが、前提条件と後続被害を減らせます。

第五に、監視では権限昇格チェーンに注目すること。
リモート入口だけでなく、異常プロセス、機密ファイル読み取り、カーネルモジュール読み込み、コンテナ脱出兆候、CI Runner異常、/etc/shadow、SSH host keyなど高価値ファイルへのアクセスを見る必要があります。

オープンソースコミュニティにとっての意味

Linuxコミュニティや大規模オープンソースプロジェクトにとって、AIによる脆弱性発見は二重の圧力をもたらします。

一方で、AIは防御側が古い問題をより速く見つける助けになります。より多くの潜伏脆弱性が公開修正されることは、長期的には良いことです。

他方で、AIはノイズも生みます。低品質な自動報告、誤検知、重複報告、文脈のない「AIがbugを見つけた」という主張は、メンテナの時間を消耗します。本当の課題は「AIを使うか」ではなく、AIの出力を責任あるセキュリティプロセスへどう組み込むかです。

報告には最小再現が必要。
影響範囲と脅威モデルを明確にする必要がある。
理論上の問題、発火可能なbug、悪用可能な脆弱性を区別する必要がある。
embargo、ディストリビューション調整、修正ウィンドウを尊重する必要がある。
メンテナにはより良い自動テスト、fuzzing、静的解析、回帰検証が必要。

AIは脆弱性発見を速くします。同時に、修復と調整の仕組みもより成熟する必要があります。そうでなければ、セキュリティ研究の生産性向上は、メンテナの負担とユーザーの不安に変わります。

結論：神話崩壊ではなく、セキュリティ現実が変わった

Linuxは今も、主流OSインフラの中で最も透明で、制御可能で、修復と強化が可能な基盤の一つです。問題はLinuxが突然「安全でなくなった」ことではありません。現代カーネルの複雑性、クラウドネイティブな使われ方、AI支援の脆弱性発見が、脆弱性露出の速度を変えていることです。

今後も似た事件は起きる可能性が高いでしょう。毎回新しい災害が起きているからではなく、過去に蓄積された複雑な経路が、より高効率に探索されるようになったからです。

本当に変えるべきなのは、私たちの安全仮定です。

「脆弱性が公開されていない」を「脆弱性がない」と見なさない。
「ローカル権限昇格」を低リスクと見なさない。
「コンテナ隔離」を強い安全境界と見なさない。
数千万行級のシステムソフトウェアを人工レビューだけで守れると思わない。
パッチを待つだけでなく、攻撃面を縮小し、パッチ速度を上げ、多層防御を作る。

AIは脆弱性発見を高い生産能力の時代へ押し出しました。攻撃者にとっても、防御者にとっても同じです。違いは、防御側がこの能力をより速い監査、より早い修正、より安定したインフラ治理へ変えられるかどうかです。

参考資料

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 への依存を評価し、露出度の高いマシンを優先して更新し、「ディスクファイルが変わっていない」ことが「システムが影響を受けていない」ことを意味しないと理解することです。

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