Dirty Frag 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 CVE-2026-43284：Linux ローカル権限昇格のリスクと緩和ガイド

Sat, 09 May 2026 07:25:55 +0800

Dirty Frag は、2026 年 5 月に公開され、実際の悪用の兆候も報告されている Linux kernel local privilege escalation 脆弱性群である。Microsoft は、攻撃者がすでに低権限の code execution を得た後に root へ昇格する post-compromise risk として説明している。Ubuntu も CVE-2026-43284 を High として扱っている。

この種の脆弱性で危険なのは、「remote から一発で侵入される」ことではない。「侵入後に権限を一気に広げられる」ことだ。攻撃者が弱い SSH account、WebShell、container escape、低権限 service account、phishing 後の remote access などで local execution を得ると、Dirty Frag を使って root を取得し、security tooling の停止、credential の読み取り、log 改ざん、lateral movement、persistence につなげる可能性がある。

Dirty Frag に関係する CVE

現在の公開情報では、Dirty Frag は主に二つの番号と関係している。

CVE-2026-43284：Linux kernel の xfrm/ESP path に関係する。Microsoft が言及する esp4、esp6 はこのリスク領域に含まれる。
CVE-2026-43500：Microsoft は rxrpc に関連すると説明しているが、2026 年 5 月 8 日時点では NVD にまだ正式公開されておらず、patch status も変化中である。

したがって、実際の確認では一つの CVE だけを見るべきではない。esp4、esp6、rxrpc、関連する xfrm/IPsec 機能が有効か、必要か、distribution kernel patch があるかをまとめて確認するのが安全だ。

技術的な概要

Microsoft と Ubuntu の説明によると、CVE-2026-43284 は Linux kernel の networking と memory-fragment handling、特に ESP/IPsec path における shared page fragments の扱いに関係する。

簡単に言えば、data page は splice などの仕組みで network buffer に attach されることがある。その後の kernel path が、それらの fragment を privately owned data とみなして in-place modification できるものとして扱うと、本来書き込むべきでない場所で in-place decrypt や modification が起きる可能性がある。攻撃者はこれを利用して page cache behavior を操作し、最終的に local privilege escalation を達成し得る。

これは以前公開された CopyFail（CVE-2026-31431）と背景が似ている。どちらも Linux page cache、kernel data path、local privilege escalation を中心にしている。Dirty Frag が危険なのは、追加の attack path を持ち、狭い race window に依存する従来型 LPE より安定しやすい可能性がある点だ。

優先的に見るべき環境

Dirty Frag は local privilege escalation なので、攻撃者がすでに対象 machine 上で code を実行できることが前提になる。優先的に確認すべき環境は次の通り。

SSH を公開している Linux server。
WebShell を書き込まれる可能性がある Web application server。
multi-user login host、bastion、developer machine、CI/CD runner。
container host、Kubernetes node、OpenShift node。
IPsec、VPN、xfrm、RxRPC 関連機能を使う system。
Ubuntu、RHEL、CentOS Stream、AlmaLinux、Fedora、openSUSE など主要 distribution を動かす server。

local multi-user、container、露出した application path がまったくない server ではリスクは低めだ。しかし「攻撃者が low-privileged shell を得る可能性」がある system では、高優先度の kernel vulnerability として扱うべきである。

まず patch を優先する

最も確実な修正は、distribution が提供する kernel security update をインストールし、新しい kernel で reboot することだ。

Ubuntu の CVE page では、CVE-2026-43284 は 2026 年 5 月 8 日に公開され、priority は High とされている。Microsoft も Linux Kernel Organization が CVE-2026-43284 の修正を公開しており、できるだけ早く patch を適用するよう促している。

まず system を確認する。

1
2

uname -a
cat /etc/os-release

distribution に合わせて kernel を更新する。

`1`	`sudo apt update && sudo apt full-upgrade`

または：

`1`	`sudo dnf update`

更新後は、新しい kernel で起動していることを必ず確認する。

`1`	`uname -r`

kernel package をインストールしただけで reboot していない場合、古い kernel が動き続けるため、脆弱性は残る可能性がある。

暫定緩和：関連 module を無効化する

patch がまだない、または production をすぐ reboot できない場合は、関連 module を一時的に無効化できるか評価する。Ubuntu の緩和策は、esp4、esp6、rxrpc の loading を block し、すでに loaded なら unload するというものだ。

modprobe block rule を作成する。

1
2
3

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

early boot で module が load されないよう initramfs を更新する。

`1`	`sudo update-initramfs -u -k all`

すでに loaded な module を unload する。

`1`	`sudo rmmod esp4 esp6 rxrpc 2>/dev/null`

module がまだ loaded か確認する。

`1`	`grep -qE '^(esp4\|esp6\|rxrpc) ' /proc/modules && echo "Affected modules are loaded" \|\| echo "Affected modules are NOT loaded"`

module が業務で使われている場合、unload に失敗することがある。その場合、block rule は reboot 後に有効になる可能性が高い。

無効化前に業務影響を確認する

上の緩和コマンドをそのまま貼り付けてはいけない。esp4、esp6、xfrm/IPsec 関連機能は、VPN、tunnel、encrypted networking、Kubernetes/container networking、企業 network configuration で使われている可能性がある。rxrpc も、その protocol に依存する workload に影響する。

production で実行する前に、少なくとも次を確認する。

1
2
3

lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

IPsec VPN や関連 kernel networking に依存している場合、module 無効化で接続が切れる可能性がある。その場合は、module block に長く頼るより、kernel patch と maintenance reboot を早めに計画するべきだ。

侵害後確認を省かない

Microsoft は、緩和策だけでは成功した exploit による変更を元に戻せない可能性があると強調している。攻撃者がすでに root を得ていた場合、persistence、file modification、log tampering、session data access が残っている可能性がある。

少なくとも次を確認する。

journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

特に次を見る。

異常な su、sudo、SUID/SGID process launch。
最近追加された ELF executable。
Web directory 内の怪しい PHP、JSP、ASP file。
SSH authorized_keys の変更。
systemd service、cron、rc.local に追加された persistence。
container host 上の異常な privileged container や mount。

悪用が疑われる場合は、host を isolate し、evidence を保存し、credential を rotate してから cleanup する。module unload や cache clearing だけで安全になったと考えてはいけない。

drop_caches について

Microsoft は、一部の post-exploitation integrity verification で cache clearing を検討できると述べている。

`1`	`echo 3 \| sudo tee /proc/sys/vm/drop_caches`

これは vulnerability fix でも incident cleanup command でもない。cache clearing は追加の disk I/O と production performance への影響を起こし得る。影響を理解したうえで補助操作として使うべきだ。本当の修正は patch、reboot、integrity verification、persistence check である。

推奨対応順序

production environment では、次の順序が比較的安全だ。

Linux asset と kernel version を棚卸しする。
exposed SSH、Web workload、container host、multi-user system を優先する。
reboot できる system は早急に patch して新 kernel で起動する。
まだ patch または reboot できない system は、esp4、esp6、rxrpc の無効化を評価する。
su、SUID/SGID、異常 ELF、WebShell、container escape indicator の監視を強化する。
悪用が疑われる host では侵害後確認と credential rotation を行う。

まとめ

Dirty Frag は「remote one-click」脆弱性ではないが、侵害後のリスクを大きく高める。攻撃者が local で低権限 code execution を得るだけで、CVE-2026-43284 と関連する rxrpc attack surface を使って root へ昇格できる可能性がある。

管理者にとって重要なのは PoC 研究ではない。kernel が影響を受けるかを確認し、distribution security update をインストールして reboot すること。patch window 前には関連 module の無効化を評価すること。そして露出している system や疑わしい system では integrity と persistence を確認することだ。

参考リンク：