コンテナセキュリティ on KnightLiブログ

最近の Linux ローカル脆弱性 4 件の影響整理：Copy Fail、Dirty Frag、Fragnesia、ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

最近、Linux エコシステムでは注目度の高いローカルセキュリティ問題が相次いでいる。個別に見ると、暗号インターフェース、ネットワーク/IPsec 経路、ページキャッシュ処理、ptrace アクセスチェックなど、発生箇所は異なる。だがまとめて見ると、運用上の教訓は同じだ。攻撃者が低権限のローカル実行点を得た時点で、Linux ホスト、コンテナノード、CI マシン、マルチユーザーサーバーのリスクは大きく増える。

この記事では各脆弱性の技術詳細を繰り返さず、実環境への影響を整理し、詳しい解説としてサイト内の 4 本の記事へリンクする。

4 つの問題は何に影響するのか

最近特に追うべきリスクは次の 4 つだ。

Copy Fail（CVE-2026-31431）：低権限のローカルユーザーがカーネル暗号関連経路を通じてページキャッシュに影響し、権限を拡大する可能性がある。
Dirty Frag（CVE-2026-43284 / CVE-2026-43500 関連）：xfrm/ESP、RxRPC などのネットワークおよびカーネルデータ経路にリスクが集中し、侵害後の段階で危険性が高い。
Fragnesia（CVE-2026-46300）：Dirty Frag に近く、XFRM ESP-in-TCP、共有 fragment、ページキャッシュ書き込みリスクをめぐる問題。
ssh-keysign-pwn（CVE-2026-46333）：直接 root shell を得るタイプではなく、SSH ホスト秘密鍵や /etc/shadow などを読まれる可能性があるローカル情報漏えいリスク。

この 4 種類は入口が異なり、緩和策も完全には同じではない。Copy Fail を処理したから Dirty Frag と Fragnesia も安全とは言えない。ネットワークモジュールの一部を無効化したから ssh-keysign-pwn の情報漏えいリスクが消えるわけでもない。

Copy Fail：コンテナと CI ノードの優先度が高い

Copy Fail の重要な影響は「アプリが落ちる」ことではなく、低権限の実行能力が root 権限に変わる可能性があることだ。特に影響が大きいのは次の環境である。

ユーザーがコードをアップロードまたは実行できる CI/CD ノード。
信頼できないワークロードを動かすコンテナホスト。
開発・テスト機、踏み台、共有サーバー。
古いカーネルを使い、パッチ適用の遅いクラウドホスト。

Copy Fail が危険なのは、攻撃のハードルが比較的低く、コンテナ環境と重なりやすいためだ。多くのチームはコンテナを強い隔離境界のように扱うが、通常のコンテナはデフォルトでホストカーネルを共有している。攻撃者がコンテナ内で shell を得られるなら、カーネル LPE によってコンテナ内の問題がホスト全体の問題に拡大する可能性がある。

詳細解説：Copy Fail CVE-2026-31431：Linux カーネルのファイルコピー経路におけるコンテナエスケープリスク。

Dirty Frag：侵害後の権限拡大装置

Dirty Frag は、攻撃者がシステムに入った後の権限拡大ツールに近い。典型的なリモート未認証脆弱性ではなく、通常は弱いパスワード、WebShell、低権限サービスアカウント、コンテナタスクなどを通じて、すでにローカル実行能力を得ていることが前提になる。

実際の影響は主に次の通りだ。

侵害済みの低権限アカウントが root になる可能性がある。
コンテナ内の低権限実行点がホストを脅かす可能性がある。
IPsec、ESP、RxRPC、関連するカーネルネットワーク機能を使うシステムは、パッチと一時緩和を慎重に評価する必要がある。
セキュリティチームは境界防御だけでなく、侵害後の権限昇格チェーンも見る必要がある。

Dirty Frag は、ローカル権限昇格が最初の入口でなくても、侵入がどこまで広がるかを決め得ることを示している。低権限の足場があれば、攻撃者はカーネルバグを探して最高権限へ進もうとする。

詳細解説：Dirty Frag CVE-2026-43284：Linux ローカル権限昇格のリスクと緩和ガイド。

Fragnesia：同系統の攻撃面は一度では片付かない

Fragnesia が重要なのは、Dirty Frag 周辺の攻撃面が単発の孤立した問題ではないことを示している点だ。あるバグが修正されても、隣接経路、似たデータ構造、関連モジュールの組み合わせに新しい利用可能な点が残る可能性がある。

運用への影響は主に次の通りだ。

脆弱性名だけで一度きりの対応をするのではなく、攻撃面として継続的に確認する。
esp4、esp6、rxrpc、XFRM、ESP-in-TCP などの関連経路を、実際の業務依存と照らして評価する。
関連するネットワーク機能を使っていないなら一時的な無効化を検討できるが、VPN、IPsec、トンネル、内部ネットワークに影響しないか先にテストする必要がある。
ページキャッシュ汚染型のリスクは、ファイル自体は変わっていないように見えても実行経路が影響を受ける、という検知の盲点を作り得る。

企業にとって最大の教訓は、パッチ管理を単一 CVE だけで見ないことだ。より安全なのは、サブシステムと攻撃面を軸に棚卸しし、どのマシンが関連機能を露出しているのか、どの業務が本当にそのモジュールを必要としているのかを確認することだ。

詳細解説：Fragnesia (CVE-2026-46300)：Linux カーネルローカル権限昇格の影響と緩和。

ssh-keysign-pwn：直接 root でなくても危険

ssh-keysign-pwn は前の 3 件とは性質が異なる。直接 root shell を取る脆弱性ではなく、ローカルの機密情報漏えいに近い。しかし実際の攻撃では、機密情報の漏えいがより深刻な結果につながることが多い。

主な影響は次の通り。

SSH host private keys が漏えいすると、ホスト ID の信頼性に影響する可能性がある。
/etc/shadow などのファイルを読まれると、オフラインクラッキングやアカウント乗っ取りにつながる可能性がある。
マルチユーザーサーバー、踏み台、ビルドマシン、共有開発機のリスクが高い。
攻撃者がすぐに権限昇格しなくても、後続の横展開に使える認証情報を得る可能性がある。

この種の問題は、直接 root shell ほど派手ではないため過小評価されやすい。だが企業環境では、鍵やパスワードハッシュの漏えいは長い後処理を意味する。SSH ホスト鍵のローテーション、信頼関係の確認、アカウントパスワードの確認、ログインログ監査が必要になる可能性がある。

詳細解説：ssh-keysign-pwn（CVE-2026-46333）解説：Linux ローカル情報漏えい、SSH ホスト鍵、/etc/shadow のリスク。

共通の影響：コンテナ隔離を強い境界と見なせない

この 4 件を合わせると、最も直接的な影響は、通常のコンテナ隔離は仮想マシン隔離ではないという再確認だ。

Docker、containerd、Kubernetes は namespace、cgroup、capabilities、seccomp、AppArmor、SELinux などで攻撃面を減らすが、通常はホストカーネルを共有している。脆弱性が共有カーネルにあるなら、コンテナ内の低権限実行点が攻撃の入口になる。

高リスク環境では次を確認すべきだ。

信頼できないコードを共有ホスト上で実行していないか。
コンテナがデフォルトで root ユーザーとして動いていないか。
不要な capabilities を付与していないか。
seccomp ポリシーが広すぎないか。
マルチテナントワークロードを gVisor、Kata Containers、Firecracker microVM、専用 VM、専用ノードへ移すべきか。

CI/CD プラットフォームは特に注意が必要だ。ビルドジョブは外部コード、依存関係のインストールスクリプト、テストスクリプト、一時バイナリを自然に実行する。これらが長期稼働サービスとホストを共有している場合、1 つのローカル権限昇格が大きなインフラに波及する可能性がある。

共通の影響：パッチは「実行中のカーネル」まで届く必要がある

Linux カーネルのパッチ適用でよくある誤解は、パッケージがインストールされたことと、マシンが修正済みカーネルで動いていることを混同することだ。

運用では少なくとも 3 点を確認する。

`1`	`uname -a`

現在実行中のカーネルを確認する。

`1`	`dpkg -l \| grep linux-image`

RHEL 系ディストリビューションでは次のように確認する。

`1`	`rpm -qa \| grep kernel`

インストール済みカーネルパッケージを確認する。

最後に、マシンが修正済みカーネルで再起動済みかを確認する。すぐ再起動できない重要サービスでは livepatch、ホットパッチ、短期隔離を検討する。ただし一時緩和を最終修正と考えてはいけない。

共通の影響：攻撃面最小化はモジュールと syscall まで具体化する

今回の経路は、Linux の堅牢化が「更新する」「ファイアウォールを入れる」だけでは不十分であることを示している。

より具体的な確認項目は次の通り。

AF_ALG / algif_aead を業務で使っているか。
XFRM、ESP、ESP-in-TCP、IPsec が VPN、トンネル、セキュリティゲートウェイに必要か。
RxRPC が必要か。
非特権 user namespace を有効にする必要があるか。
コンテナが広すぎる socket タイプを作成できるか。
ptrace アクセスポリシーが緩すぎないか。

業務上不要な機能であれば、モジュール無効化、sysctl 調整、seccomp の強化、capabilities の削減を評価できる。本番環境にコマンドをそのまま貼り付けるのではなく、依存関係を棚卸しし、段階的に展開するべきだ。

推奨される対応順序

第一に、ローカルコード実行が露出している高リスクマシンを優先して修正する。

コンテナホスト。
CI/CD runner。
踏み台。
マルチユーザーサーバー。
外部公開サービスのホスト。
信頼できないプラグイン、スクリプト、拡張を動かすシステム。

第二に、ディストリビューションのアドバイザリと実際の実行中カーネルを確認する。上流のバージョン番号だけを見てはいけない。Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、SUSE、openEuler などはセキュリティ修正を backport することがある。

第三に、コンテナ実行ポリシーを締める。非 root ユーザー、最小 capabilities、no-new-privileges、読み取り専用ファイルシステム、明示的な seccomp と AppArmor/SELinux ポリシーを優先する。

第四に、鍵と認証情報のリスクを確認する。特に ssh-keysign-pwn が関係する環境では、SSH host key、/etc/shadow、踏み台の認証情報、CI secrets のローテーションが必要か評価する。

第五に、監視を補う。異常な root shell、不審なローカル LPE PoC、重要ファイルの変更、異常な ptrace 動作、コンテナプロセスによるホストパスへのアクセス、CI ノードからの異常なネットワーク接続を重点的に見る。

結論

この 4 件の要点は「Linux が安全でなくなった」ではなく、「デフォルトの信頼だけでは足りなくなった」だ。

Linux は今も透明で、修正でき、切り詰められ、堅牢化できる主流システムである。しかしコンテナ、CI、マルチテナント、AI による自動コード実行が広がる環境では、低権限の実行点を小さな問題と見なせなくなっている。カーネルに利用可能なローカル権限昇格や機密情報漏えいのバグがあれば、局所的な侵入はホスト制御、認証情報漏えい、横展開につながり得る。

より現実的な対応は、この 4 件を警告として受け止めることだ。パッチを早く適用し、再起動済みカーネルを確認し、モジュールは必要なものだけ有効化し、コンテナを締め、鍵をローテーションできるようにし、マルチテナントの隔離レベルを再評価する。

サイト内の関連解説:

Copy Fail 脆弱性 CVE-2026-31431：Linux カーネルのファイルコピー経路におけるコンテナエスケープリスク

Fri, 01 May 2026 18:42:34 +0800

Copy Fail は Linux カーネルのファイルコピー経路に影響する脆弱性で、CVE-2026-31431 として管理されている。 Bugcrowd の分析では、これは注意すべきカーネルレベルの問題とされている。特定の条件下で、非特権ユーザーがファイルコピー関連のロジックを悪用し、不正な書き込みを引き起こせる可能性があり、その結果として権限昇格やコンテナエスケープにつながる。

リスクの観点では、これは通常のアプリケーション層の脆弱性ではない。問題はカーネルがファイルコピーとページキャッシュを処理する経路で発生するため、影響はコンテナ、共有ホスト、CI/CD Runner、PaaS プラットフォーム、マルチテナント Linux 環境にまで及ぶ。攻撃者がすでにシステム内で低権限コードを実行できる場合、この脆弱性は隔離境界を突破するための足がかりになり得る。

脆弱性はおおよそどこで発生するのか

Copy Fail は Linux カーネルのファイルコピー機能に関係している。現代の Linux には、copy_file_range、splice 系の経路、異なるファイルシステム間のデータコピー最適化など、複数の効率的なコピー経路がある。これらの仕組みは、ユーザー空間とカーネル空間の間のデータ移動を減らし、大きなファイルコピーの性能を高めるために用意されている。

問題は、高性能なコピー経路がページキャッシュ、ファイルオフセット、権限チェック、ファイルシステムコールバックを再利用することが多い点にある。どこかの境界条件の処理が厳密でない場合、カーネルが誤った権限コンテキストで書き込みを行ったり、本来攻撃者が変更できないデータページを制御できる形で露出したりする可能性がある。

Copy Fail の主なリスクは次のように整理できる。

攻撃者は root 権限を必要としない。
攻撃入口は一般的なファイルコピー機能にある。
影響点はカーネル空間にある。
コンテナ環境では、namespace やマウント隔離を迂回する可能性がある。
悪用に成功すると、コンテナが変更できないはずのホスト上の内容へ書き込める可能性がある。

これが Copy Fail が大きく取り上げられる理由である。コンテナセキュリティは Linux カーネルが提供する隔離機能に依存している。カーネル経路そのものに不正書き込みがあると、コンテナ境界は脆くなる。

なぜコンテナ環境でより敏感なのか

コンテナは仮想マシンではない。コンテナ内のプロセスとホストは同じ Linux カーネルを共有しており、namespace、cgroup、capability、seccomp、AppArmor/SELinux などの仕組みによって隔離されている。

脆弱性がユーザー空間サービスにある場合、通常は一つのコンテナや一つのプロセスに影響が限定される。しかし脆弱性がカーネルにあり、しかも非特権ユーザーからトリガーできる場合、攻撃者はコンテナ内部からホストへ影響を及ぼす可能性がある。

Copy Fail の危険性はここにある。多くのプラットフォームでは、ユーザーがビルドジョブを投入したり、スクリプトを実行したり、コンテナを起動したり、プラグインを動かしたりできる。攻撃者がコンテナ内でコードを実行できるだけで、カーネルのファイルコピー経路を利用して隔離を突破しようとする可能性がある。

高リスクな環境には次のようなものがある。

Kubernetes クラスター内の信頼できないワークロード。
CI/CD プラットフォームの共有 Runner。
ユーザーがコードをアップロードして実行できるサンドボックス。
マルチテナント Linux ホスト。
コンテナ化された PaaS。
サードパーティ製プラグインや拡張を実行するシステム。

これらの環境で影響を受けるカーネルが使われており、追加の制限が不足している場合、リスクは明らかに高まる。

影響範囲はカーネルのパッチ状態を見る必要がある

この種の脆弱性は、ディストリビューション名だけでは判断できない。同じ Ubuntu、Debian、RHEL、Fedora、Arch であっても、影響を受けるかどうかは実際に実行中のカーネルパッケージと、ディストリビューションが修正をバックポート済みかどうかに依存する。

調査では、まず次の三点を確認する。

現在実行中のカーネルバージョン。
ディストリビューションのセキュリティアドバイザリに CVE-2026-31431 が含まれているか。
クラウドベンダーやマネージドプラットフォームがホストカーネルを修正済みか。

まずシステム上でカーネルバージョンを確認する。

`1`	`uname -a`

そのうえで、ディストリビューションのセキュリティアドバイザリ、カーネル changelog、クラウドプラットフォームの告知を確認する。多くのエンタープライズディストリビューションは古いカーネルブランチへセキュリティ修正をバックポートするため、メジャーバージョンだけで安全かどうかを判断してはいけない。

一時的な緩和策

最も確実な修正はカーネル更新である。ただし、すぐにパッチを展開できない環境では、まず露出面を下げることができる。

一般的な緩和の方向性は次の通り。

信頼できないユーザーに特権コンテナを実行させない。
コンテナへ機密性の高いホストパスをマウントしない。
コンテナの capability を絞り、特に不要な CAP_SYS_ADMIN を付与しない。
seccomp、AppArmor、SELinux で危険なシステムコールとファイルアクセスを制限する。
信頼できないワークロードを、より隔離の強い仮想マシンへ移す。
CI/CD Runner はジョブごとに破棄し、同じホストを長期間使い回さない。
異常なファイル書き込み、権限変更、コンテナエスケープの兆候を監視する。

これらの対策はパッチの代替にはならない。目的は、パッチが本番環境に届くまでの間、悪用成功率と影響範囲を下げることである。

修正の優先順位

環境のリスクに応じて優先順位を付けるのがよい。

優先して修正すべきもの：

外部にコンテナ実行機能を提供するプラットフォーム。
信頼できないコードを実行する CI/CD ノード。
マルチテナント Kubernetes ノード。
ユーザー定義プラグインやスクリプト実行機能を持つシステム。
共有開発機、教育用マシン、実験環境。

相対的に優先度が低いもの：

単一ユーザーのデスクトップ。
信頼済みサービスだけを実行する内部ホスト。
信頼できないコードをすでに仮想マシンで隔離している環境。

リスクが低い場合でも、ディストリビューション経由でカーネルを更新することを推奨する。カーネル脆弱性はより複雑な攻撃チェーンに組み込まれることが多く、パッチを遅らせる利点はあまりない。

運用チーム向けチェックリスト

次の順序で対応できる。

すべての Linux ホストとコンテナノードを棚卸しする。
信頼できないコードを実行するマシンを特定する。
現在のカーネルバージョンとディストリビューションのセキュリティアドバイザリを確認する。
高リスクノードを優先して更新する。
すぐに更新できないノードには一時的な隔離ポリシーを適用する。
コンテナランタイム設定を確認し、不要な特権とホストマウントを削除する。
更新後にノードを再起動し、新しいカーネルが実際に有効になっていることを確認する。
後続の監査に備えて変更記録を残す。

カーネルパッケージをインストールしただけでは、システムが新しいカーネルで動いているとは限らない。更新後は必ず再起動し、再度確認する。

`1`	`uname -a`

まとめ

Copy Fail / CVE-2026-31431 の要点は、どこかのアプリケーションがクラッシュすることではなく、Linux カーネルのファイルコピー経路に権限境界の問題があることだ。非特権コードが、より高い権限のデータ書き込み経路へ触れる機会を持つため、コンテナ環境やマルチテナント環境では特に注意が必要である。

この種の脆弱性に対応するうえで重要なのは次の二点だ。

ディストリビューションまたはクラウドベンダーが提供するカーネルパッチをできるだけ早く適用する。
パッチ展開前は、信頼できないコード、特権コンテナ、機密性の高いホストマウントを制限する。

個人デスクトップでは、すぐに慌てる必要がある問題ではないかもしれない。しかし、コンテナプラットフォーム、CI/CD、サンドボックス、共有ホストを運用しているチームにとっては、高優先度のカーネルセキュリティ更新として扱うべきである。

参考ソース：