JFrog Security Researchは2026年6月25日、Linuxカーネルに存在するローカル権限昇格(LPE)脆弱性「DirtyClone」(CVE-2026-43503、CVSSスコア8.8)の技術的詳細と概念実証コード(PoC)を公開しました。
この脆弱性はDirty Frag(CVE-2026-43284・CVE-2026-43500)およびFragnesia(CVE-2026-46300)と同じ系譜に属するDirtyFragファミリーの新たなバリアントで、Linuxページキャッシュを操作することで非特権のローカルユーザーがroot権限を取得できます。
パッチ自体は2026年5月21日にカーネルメインラインにマージ済みですが、DirtyFragファミリーの修正パッチを段階的に適用している環境では、すべてのパッチが適用されていない限り依然として悪用可能な状態にある点に注意が必要です。
サマリー
- JFrog Security Researchが2026年6月25日、Linuxカーネルの権限昇格脆弱性DirtyClone(CVE-2026-43503、CVSS 8.8)の技術詳細とPoCを公開
- DirtyFragファミリーの3つ目のバリアント。Dirty Frag・Fragnesiaの修正で見落とされていた
__pskb_copy_fclone()の別経路が悪用される - 非特権ユーザーがLinuxページキャッシュを操作してroot権限を取得でき、攻撃はカーネルログや監査トレースを残さない
- 影響を受けるのは非特権ユーザー名前空間が有効なDebian・Ubuntu・Fedora等。マルチテナントクラウド・Kubernetesクラスタ・コンテナ環境でリスクが高い
- パッチは2026年5月21日にマージ済み(v7.1-rc5が最初の修正バージョン)。DirtyFragファミリーの修正チェーン全体の適用が必要
- 即時パッチ適用が困難な場合の暫定策として、非特権ユーザー名前空間の無効化またはesp4・esp6・rxrpcモジュールのブラックリスト登録が有効
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-43503 |
| 通称 | DirtyClone |
| CVSSスコア | 8.8(High) |
| 種別 | ローカル権限昇格(LPE) |
| 発見者 | JFrog Security Research(Eddy Tsalolikhin・Or Peles) |
| カーネルへの報告日 | 2026年5月19日 |
| パッチマージ日 | 2026年5月21日(commit 48f6a5356a33) |
| CVE公開日 | 2026年5月23日 |
| 初の修正バージョン | Linux v7.1-rc5(2026年5月24日) |
| 影響を受けるOS | 非特権ユーザー名前空間が有効なDebian・Ubuntu・Fedora等 |
| 攻撃条件 | CAP_NET_ADMIN権限(非特権ユーザー名前空間経由で取得可能) |
| 高リスク環境 | マルチテナントクラウド・Kubernetesクラスタ・コンテナワークロード |
| 悪用の痕跡 | カーネルログ・監査トレースなし。ディスク上のファイルは無変更 |
| PoCの公開日 | 2026年6月25日(JFrog) |
| 攻撃の悪用確認 | 本稿執筆時点で未確認 |
目次
DirtyFragファミリーの系譜とDirtyCloneの位置づけ
2026年4月末から5月にかけて、Linuxカーネルのコアネットワークスタックにおける権限昇格脆弱性が連続して公表されてきました。
共通するのは、ソケットバッファ(skb)が共有ページキャッシュメモリを参照する仕組みと、XFRM/IPsecやRxRPCといったサブシステムで行われる暗号化処理の組み合わせが引き起こす脆弱性パターンです。JFrogはこれらを総称して「DirtyFragファミリー」と呼んでいます。
最初のDirty Fragは2026年5月4日にカーネルメインラインへのパッチが適用されました。
このパッチは、UDPパケットがspliceされた際にSKBFL_SHARED_FRAGフラグ(共有ページキャッシュメモリを参照していることを示すメタデータ)が付与されていなかった問題を修正しています。次のFragnesiaは2026年5月13日に公開され、skbのコアレッシング処理の際にこのフラグが失われるという別の経路が問題になりました。
DirtyCloneはさらにその次の抜け穴として、JFrogの研究者Eddy Tsalolikhin氏とOr Peles氏がカーネルパッチの監査中に独自に発見したものです。
JFrogが気づいたのは、これまでの修正がXFRM/IPsecサブシステムの特定の処理経路に限定されていた点です。
__pskb_copy_fclone()という別のパケットクローニング関数でも同じフラグの欠落が発生し得ることが見落とされていました。
JFrogは2026年5月19日にLinuxカーネルメンテナーへ報告し、DirtyFrag発見者のHyunwoo Kim氏が同年5月16日に投稿した関連パッチと重なるかたちでパッチがマージされ、CVE-2026-43503として登録されました。
DirtyFragファミリー全体を通じて、「ファイル用のページキャッシュ」「ゼロコピーパスで処理されるネットワークパケットデータ」「同一バッファへの暗号化・復号処理による書き戻し」という3つの役割が本来は分離されるべきなのに重複し得る構造上の問題が根本にあります。JFrogは「この攻撃プリミティブは単一の脆弱なコードパスに限定されず、複数のskb処理経路に共通して存在することが今回の研究で示された」と説明しています。
脆弱性の仕組み
DirtyCloneの悪用には、攻撃者がCAP_NET_ADMIN権限を保持または取得できることが前提になります。
Debian・Ubuntu・Fedoraのような非特権ユーザー名前空間を開放しているディストリビューションでは、ローカルの一般ユーザーが自身のユーザー名前空間内でこの権限を取得できます。
JFrogが公表した技術レポートをもとに攻撃の流れを整理します。まず攻撃者は/usr/bin/suのような特権バイナリをメモリにマップし、ページキャッシュ上にロードさせます。次にvmspliceとspliceを使って、このページキャッシュに裏付けられたメモリをskbのペイロードとして利用するUDPパケットを送信します。この操作によって、パケットバッファの実体がファイル用のページキャッシュメモリそのものになります。
ここで鍵になるのが、netfilterのTEEターゲット規則です。これが有効だとパケットがnf_dup_ipv4経由でカーネル内部で複製され、__pskb_copy_fclone()が呼ばれます。このとき、元のskbにはSKBFL_SHARED_FRAGフラグが残りますが、クローン側のskbではフラグが失われます。フラグを欠いたクローンが後段のIPsec受信パスに到達し、esp_input()が呼ばれると、IPsecはパフォーマンス上の理由からペイロードをバッファ内でそのまま(in-place)復号します。フラグがないためコピーが行われず、復号の書き戻し先はページキャッシュ上のファイルそのものです。
攻撃者はIPsecのSA(セキュリティアソシエーション)を通じてAES-CBCの鍵とIV(初期化ベクトル)を制御できます。AES-CBCではIVが最初のブロックの復号結果に影響を与えるため、既知の元のバイト列・目標バイト列・IVを組み合わせて計算することで、ページキャッシュ上の特定オフセットに予測可能なバイトを書き込む制御書き込みプリミティブが成立します。これを使って/usr/bin/suの認証チェック部分の数バイトをメモリ上でだけ改変し、変更されたバイナリを実行するとroot権限が得られます。ディスク上のファイルは一切変更されないため、一般的なファイル整合性監視ツール(FIM)やカーネルの監査ログには記録が残りません。
影響を受ける環境
JFrogが確認している影響環境はDebian・Ubuntu・Fedoraです。これらは非特権ユーザー名前空間をデフォルトで開放しているディストリビューションで、CAP_NET_ADMINの取得に追加の操作が不要です。
脆弱性が成立するカーネルの条件も明確で、DirtyFragファミリーの修正チェーン全体が適用されていないカーネルはすべて対象になります。
具体的には、CVE-2026-43284とCVE-2026-43500(Dirty Fragの原脆弱性)がまったく未適用のシステムは広く露出しています。一方、これらの初期パッチは適用済みでもCVE-2026-46300(Fragnesia)とCVE-2026-43503(DirtyClone)の後続パッチが未適用のシステムは、特定のバイパス経路で依然として悪用可能です。修正チェーン全体が完了していなければ保護されているとはいえない、という点はDirtyFragファミリー全般を通じた重要なポイントです。
JFrogが特にリスクを強調するのはマルチテナントクラウド環境・Kubernetesクラスタ・コンテナワークロードです。これらの環境ではユーザー名前空間が有効または特権コンテナが展開されているケースが多く、コンテナ内の一般ユーザーからホストのroot権限を奪取するコンテナエスケープが成立し得ます。サーバサイドエンジニアの経験からみても、CIパイプラインや検証環境のように複数のユーザーやプロセスが同一ホストを共有している構成で、この種のLPEが悪用された場合の横展開リスクは大きいと感じます。
DirtyFragファミリーの修正タイムライン
JFrogの調査報告をもとにタイムラインを整理します。
2026年5月4日、Dirty Frag(CVE-2026-43284・CVE-2026-43500)のパッチがカーネルメインラインにマージされました。UDPパケットのsplice時にSKBFL_SHARED_FRAGフラグが欠落していた問題を修正しています。
2026年5月13日、Fragnesia(CVE-2026-46300)が公開されました。skbのコアレッシング処理でフラグが失われる別の経路が原因で、netdevカーネルメーリングリストにパッチが提出されています。
2026年5月16日、DirtyFrag発見者のHyunwoo Kim氏が残っている複数のフラグ転送ヘルパー(__pskb_copy_fclone・skb_shift・skb_segment・skb_gro_receive等)を対象とするアップストリームへの包括的なパッチを提出しました。
2026年5月19日、JFrogが__pskb_copy_fcloneの脆弱なバリアントを独自に発見し、PoCを構築してカーネルメンテナーへ報告しました。
2026年5月21日、パッチがメインラインにマージされました(commit 48f6a5356a33)。
2026年5月23日、CVE-2026-43503が公開されました。
2026年5月24日、Linux v7.1-rc5がリリースされ、これが最初の修正済みタグとなります。
2026年6月25日、JFrogが技術的詳細とPoCを公開しました。
パッチ適用と暫定措置
JFrogはLinuxカーネルをv7.1-rc5または各ディストリビューションがリリースしているCVE-2026-43503のバックポートパッチに更新することを推奨しています。繰り返しになりますが、DirtyFragファミリーの修正は段階的に行われているため、Dirty Fragのパッチだけ・FragnesiaのパッチだけというようにAとBの修正だけで完結したと見なすのは危険です。CVE-2026-43284・CVE-2026-43500・CVE-2026-46300・CVE-2026-43503という4つのCVEに対応した修正パッチがすべて揃って初めてこのファミリーへの対策が完了します。
即時のカーネルアップデートが難しい場合の暫定策として、JFrogは2つを挙げています。ひとつは非特権ユーザー名前空間を無効化することで、kernel.unprivileged_userns_clone=0を設定することで攻撃のエントリポイントであるCAP_NET_ADMINの取得経路を遮断できます。ただし、この設定はrootlessコンテナやPodman等のユーザー名前空間依存のアプリケーションに影響するため、事前に環境への影響を確認が必要です。もうひとつは、暗号化処理をインプレースで行うkernel subsystemであるesp4・esp6・rxrpcモジュールをブラックリストに登録して無効化する方法です。これはDirty FragのモジュールブラックリストがDirtyCloneにも有効という点で、Fragnesiaの暫定策と共通しています。
ネットワークエンジニアとしてLinuxサーバを扱ってきた観点からは、特にKubernetesノードや汎用Linuxサーバでsysctl kernel.unprivileged_userns_cloneの現在値を確認し、必要に応じてesp4/esp6モジュールのロード状況をチェックすることを即時に実施することをお勧めします。本脆弱性の悪用は本稿執筆時点では実際の攻撃への悪用は確認されていませんが、JFrogのPoCが公開されたことで攻撃者の参入障壁は下がっています。
2026年に相次いだLinuxカーネルLPEの連鎖
本脆弱性は2026年に相次いで公開されたLinuxカーネルのページキャッシュ汚染型LPE脆弱性の系譜における7例目として位置づけられます。Dirty Frag・Fragnesia・DirtyCloneはXFRM/IPsec系統、PinTheftはRDS/io_uring系統、CIFSwitchはCIFS認証系統、CVE-2026-46331(act_pedit COW)はtcのpeditアクション系統と、それぞれ異なるサブシステムが標的になっています。JFrogが「攻撃プリミティブは単一のコードパスに限定されない」と結論づけているように、Linuxカーネルのメモリ管理とネットワーク処理の境界に関するセキュリティ研究が集中しており、今後も同系統の発見が続く可能性があります。
情報システム部門の観点では、CVEをトリガーとする脆弱性スキャナーだけに頼るのではなく、ディストリビューションベンダーのセキュリティアドバイザリ(Ubuntu Security Notices・Debian Security Tracker・Red Hat Security Advisoryなど)を定期的に確認し、カーネルアップデートを管理サイクルに組み込む運用体制の整備が引き続き重要です。
出典
当サイト関連記事:








