DirtyClone(CVE-2026-43503): Linux skbuffのshared-frag伝播漏れでページキャッシュ汚染、root昇格

2026年6月25日、JFrog Security Researchは、Linuxカーネルのネットワークスタックに残っていたローカル権限昇格脆弱性「DirtyClone」(CVE-2026-43503)の技術解説を公開しました。この脆弱性は、ローカル非特権ユーザーが特権バイナリのページキャッシュを汚染し、root権限取得につなげられる経路にあたります。Ubuntu SecurityのCVSS v3スコアは8.8(High)で、修正は2026年5月21日に上流へ取り込まれ、Linux v7.1-rc5に含まれています。DebianやUbuntuでは、配布元のセキュリティチャネルを通じて修正済みカーネルの提供が進んでいます。なお、本CVEはソースによって通称の扱いが異なり、JFrogは「DirtyClone」、Ubuntu Security Teamは「Fragnesia」と説明しています。

DirtyCloneは、2026年5月以降に相次いで公表されたDirtyFrag系の脆弱性と同じ問題領域に属します。具体的には、ソケットバッファ(skb)がページキャッシュ由来の共有メモリを参照していることを示すSKBFL_SHARED_FRAGフラグが、特定のskb処理経路で正しく伝播されないことで、in-place復号処理がページキャッシュへの書き込みプリミティブに転化する構造です。本稿では、DirtyCloneの攻撃チェーン、SKBFL_SHARED_FRAGの伝播漏れ、ディストリビューションごとの修正状況、実務上の対処を整理します。

DirtyCloneの全体像
1. 攻撃成立の条件
DirtyFragファミリーとSKBFL_SHARED_FRAGフラグ
根本原因 – frag-transferヘルパーでフラグが落ちる
攻撃チェーンの概略
ディストリビューション別の修正状況
命名の混在：DirtyClone、Fragnesia、CVE-2026-43503の関係
パッチが当てられない場合の緩和策
優先対処すべき環境
DirtyFragクラスは「終わっていない」
対処手順
一次情報・公式情報
参考情報

DirtyCloneの全体像

DirtyCloneは、Linuxカーネルがネットワークパケットを内部的にコピーする際に、SKBFL_SHARED_FRAGという安全マーカーが正しく伝播せず、結果としてファイルに紐づくページキャッシュ領域をネットワーク処理側からin-placeで書き換えられる可能性のある脆弱性です。攻撃者はsetuid rootバイナリ(例: /usr/bin/su)のページキャッシュをパケットの参照先に重ね、IPsec復号処理を通じてキャッシュ上のバイナリを改変し、root権限のシェルを取得する経路を取ります。ディスク上のファイルは変更されないため、AIDEやTripwireのようなファイル整合性監視では検知しにくくなります。

項目	内容
CVE	CVE-2026-43503
命名	DirtyClone(JFrog命名)。Ubuntu Security TeamはCVE-2026-43503をFragnesiaとして説明しているが、JFrogの整理ではFragnesiaは別CVE(CVE-2026-46300)を指す
脆弱性種別	frag-transferヘルパーでSKBFL_SHARED_FRAGの伝播失敗、in-place書き込み処理によるページキャッシュ汚染
影響箇所	`net/skbuff`の`__pskb_copy_fclone()`、`skb_shift()`、`skb_gro_receive()`、`skb_gro_receive_list()`、`tcp_clone_payload()`、`skb_segment()`
CVSS v3スコア	8.8(High、Ubuntu Security表記)
Ubuntuプライオリティ	Medium
CVE公開	2026年5月23日
発見者	JFrog Security Research(Eddy Tsalolikhin氏、Or Peles氏)。同時期にHyunwoo Kim氏も上流の広範な修正パッチを投稿
PoC / 技術実証	2026年6月25日、JFrog Security Researchがエクスプロイトの技術解説とウォークスルーを公開
主な影響範囲	非特権user namespacesがデフォルトで有効なディストリビューション(Debian、Ubuntu、Fedora)。修正済みカーネル未適用の環境

攻撃成立の条件

JFrogレポートによれば、DirtyCloneの悪用には以下の前提が揃う必要があります。いずれもDebian、Ubuntu、Fedoraなどのクラウド・コンテナ用途で広く展開されている設定です。

修正パッチ未適用のカーネル：DirtyFragファミリーの一連のパッチ(CVE-2026-43284、CVE-2026-43500、CVE-2026-46300、そしてCVE-2026-43503)を完全に適用していないカーネル。最初のDirtyFrag修正だけを当てたシステムは、後続のバイパスに対して脆弱なままです。
CAP_NET_ADMIN権限の獲得経路：ローカルユーザーがCAP_NET_ADMINを持つ、もしくは非特権user namespaces経由でnamespace-localにCAP_NET_ADMINを取得できる構成。多くのモダンディストリビューションでは非特権user namespacesがデフォルトで有効です。
IPsec関連モジュールの利用可能性：esp4、esp6などのIPsec関連モジュールがロード可能か、すでにロードされている環境。

DirtyFragファミリーとSKBFL_SHARED_FRAGフラグ

DirtyCloneを理解するには、まずDirtyFragファミリーの全体像を押さえる必要があります。JFrogによれば、DirtyFragはLinuxカーネルのコアネットワーキングスタックにおける一連のメモリ破損脆弱性で、ソケットバッファ(skb)がページキャッシュメモリを参照する仕組みと、XFRM/IPsec、RxRPCなどでin-place暗号変換を行う仕組みの組み合わせから生まれます。

カーネル設計の文脈では、本来分離されているべき3つのメモリの役割が存在します。1つ目はファイルに裏打ちされたメモリ(実行ファイルやファイルのページキャッシュ)、2つ目はネットワークバッファ(zero-copyパスで処理されるパケットデータ)、3つ目はin-place変換(暗号化・復号で同じバッファに書き戻す処理)です。これら3つが交差したとき、本来はファイル内容として扱われるメモリがネットワーク処理側から意図せず変更され、ページキャッシュ上のデータがin-placeで汚染される構造が成立します。

DirtyFragファミリーの初期修正(CVE-2026-43284、CVE-2026-43500)では、spliced UDPパケットに対してSKBFL_SHARED_FRAGというメタデータフラグを設定する仕組みが導入されました。このフラグは「このskbはページキャッシュ由来の共有メモリを参照している」というマーカーで、in-place復号を行うサブシステムがフラグを検知した場合、安全のためCopy-on-Writeで複製を取ってから処理を進める設計になっています。

ところが、その後の調査により、このフラグが特定のskb処理経路を通る際に「落ちる」(伝播されない)ケースが複数発見されました。Fragnesia(CVE-2026-46300)ではskb_try_coalesce()でフラグが失われ、DirtyClone(CVE-2026-43503)では__pskb_copy_fclone()を含むfrag-transferヘルパー群でフラグが落ちる構造です。

根本原因 – frag-transferヘルパーでフラグが落ちる

Debian Security Trackerに掲載されたパッチ説明によれば、CVE-2026-43503の根本原因は次のように整理されます。__pskb_copy_fclone()とskb_shift()の2つのfrag-transferヘルパーは、フラグメント記述子をsourceからdestinationに移動する際に、skb_shinfo()->flagsのSKBFL_SHARED_FRAGビットを伝播していませんでした。

__pskb_copy_fclone()はフラグメント記述子のコピー後、残りのshinfoメタデータをskb_copy_header()に委ねますが、後者はgso_{size,segs,type}のみを引き継いでflagsは触らない実装です。skb_shift()はフラグメント記述子を直接動かしますが、フラグは未変更のまま放置されます。その結果、destinationのskbは外部所有またはページキャッシュに裏打ちされたページへの参照を保持しながら、skb_has_shared_frag()がfalseを返す状態が生まれます。

このミスマッチが問題になるのは、skb_has_shared_frag()を見て共有ページをskb_cow_data()でCopy-on-Write経由に迂回させるかどうかを判断する、すべてのin-placeで書き込む処理です。ESP input(esp4.c、esp6.c)はその代表例で、netfilterのパケット複製ルールやnf_dup_ipv4()、xt_TEEといったskbの複製を引き起こす任意の処理経路を経由すれば、pskb_copy()済みのskbがマーカーなしでesp_input()に到達することになります。

同じ伝播漏れはskb_gro_receive()、skb_gro_receive_list()、tcp_clone_payload()、skb_segment()にも存在しており、CVE-2026-43503の修正パッチは、これらすべての経路でフラグを正しく伝播するよう変更を加える内容です。修正コミットは48f6a5356a33として2026年5月21日にmainlineへマージされ、Linux v7.1-rc5として5月24日にタグ付けされています。

攻撃チェーンの概略

JFrogが公開したDirtyClone攻撃チェーンは、概念レベルでは以下の7段階で整理できます。具体的なコマンドや再現コードはJFrogの公開コンテンツに含まれていますが、本稿では各段階で何が起きるかの理解に絞ります。

標的ページの確保：攻撃者は/usr/bin/suのような特権バイナリをマップし、ページキャッシュに該当ファイルを載せる
パケットからページキャッシュへの参照付け：カーネルのzero-copy機能を使い、ページキャッシュに裏打ちされたメモリをskbのペイロードとして付ける。この時点でパケットバッファは実質的にファイルメモリで裏打ちされた状態となる
ローカルIPsec処理経路の準備：ループバックベースのIPsecトンネルを構成し、パケットがローカルで処理されるようにする。あわせて、netfilterのパケット複製ルールにより、対象パケットが脆弱なclone経路を通る構成を作る
cloneでフラグが落ちる：カーネルがTEEなどによりskbをcloneする際、__pskb_copy_fclone()がSKBFL_SHARED_FRAGを伝播しない。オリジナルskbはマーカー保持で安全、cloneされたskbはマーカーなしの危険な状態になる
in-place復号が書き込みプリミティブになる：cloneされたskbがESP復号(esp_input())に到達する。IPsecは性能のため入出力バッファを同一にしてin-place復号する設計だが、cloneされたskbはページキャッシュに裏打ちされたメモリを参照しているため、復号結果がそのままファイルに裏打ちされたページに書き込まれる
暗号パラメーターを通じた書き込み制御：攻撃者はAES-CBCの鍵、IV、パケットレイアウトを制御できるため、復号結果として書き戻されるバイト列を予測可能な形に誘導できる。これによりキャッシュ上の/usr/bin/suの特定オフセットを狙った形で書き換えられる
改変済みバイナリの実行：キャッシュページが残っている状態で/usr/bin/suを実行すると、改変された認証ロジックが動作してroot権限が取得される。ディスク上のファイルは未変更のままで、ハッシュ照合や整合性監視に異常は出にくい

この一連の流れでは、root権限取得後にページキャッシュをdrop_cachesでクリアすれば、改変されたキャッシュページそのものは消滅します。攻撃の痕跡が残りにくい構造です。

ディストリビューション別の修正状況

Debian

Debian Security Trackerによれば、各リリースの修正状況は以下のとおりです。Debian側はすべてのサポート対象リリースで修正済みパッケージが用意されています。

Debian 11(bullseye)：linux 5.10.257-1で修正済み(DLA-4606-1)。バックポート版linux-6.1 6.1.174-1~deb11u1も提供されている(DLA-4607-1)
Debian 12(bookworm)：linux 6.1.174-1で修正済み(DSA-6306-1)
Debian 13(trixie)：linux 6.12.94-1で修正済み(DSA-6295-1)
Debian sid/forky：linux 7.0.12-2以降で修正済み

Ubuntu

Ubuntu公式CVEページ(本稿確認時点で2026年6月25日最終更新)によれば、generic kernelであるlinuxパッケージは以下のとおり修正済みです。

Ubuntu 26.04 LTS(resolute)：linux 7.0.0-22.22で修正済み
Ubuntu 25.10(questing)：linux 6.17.0-35.35で修正済み
Ubuntu 24.04 LTS(noble)：linux 6.8.0-124.124で修正済み
Ubuntu 22.04 LTS(jammy)：linux 5.15.0-181.191で修正済み

一方、Ubuntu 20.04 LTS以前では、generic kernelのlinuxパッケージはVulnerableまたは「work in progress」と表示されています。ただし、HWE(linux-hwe-5.15など)、AWS(linux-aws)、Azure(linux-azure)、GCP(linux-gcp)、FIPS版、Real-time版などのカーネルフレーバーでは、すでに修正済みのものや、Ubuntu Pro経由で修正利用可能なものもあります。実環境では、利用中のカーネルパッケージ名ごとにUbuntu CVEページの状態を確認してください。

Red Hat / Fedora

本稿確認時点で、Red Hat Enterprise Linux向けの修正errataは確認できませんでした。Red Hat Bugzilla 2480902ではCVE-2026-43503のトラッキングが進められており、RHEL系環境ではRed Hat CVEデータベースおよび今後のRHSA公開状況を継続して確認する必要があります。JFrogもFedoraは脆弱対象として確認したと公表しています。

命名の混在：DirtyClone、Fragnesia、CVE-2026-43503の関係

本CVEを巡って、命名がベンダーや報道機関ごとに異なる点に注意が必要です。Ubuntu Security TeamはCVE-2026-43503を「Fragnesia」として説明しており、これはXFRM ESP-in-TCPサブシステムでskbフラグメントを扱う際のロジック欠陥として整理されています。JFrog Security Researchは同じCVEに対し独自に「DirtyClone」という命名を用いており、これはCVE-2026-43503の__pskb_copy_fclone()側のバイパス経路を具体的に再現したexploit variantを指して用いられます。

JFrogの整理では、DirtyFragファミリーの命名は次のように区別されます。「DirtyFrag」はCVE-2026-43284/CVE-2026-43500を指す元のファミリー名、「Fragnesia」はCVE-2026-46300のskb_try_coalesce()経路を指す別CVE、「DirtyClone」はCVE-2026-43503の__pskb_copy_fclone()経路を指すexploit variantという位置づけです。一方、Ubuntu Security TeamはCVE-2026-43503そのものを「Fragnesia」として記述しており、JFrog命名との整理がずれています。

記事や運用文書ではCVE番号(CVE-2026-43503)を一次識別子として用い、通称(DirtyClone、Fragnesia)はソースに応じて使い分けるのが安全です。本稿ではJFrog命名の「DirtyClone」をタイトルに採用しつつ、Ubuntu表記での「Fragnesia」も併記する形を取っています。

パッチが当てられない場合の緩和策

JFrogが公式に推奨している緩和策は2系統あります。いずれも副作用がある選択肢のため、検証環境で影響を確認したうえで適用します。

1. 非特権user namespacesを無効化する

sysctlで非特権user namespacesを無効化することで、ローカル非特権ユーザーがCAP_NET_ADMINを獲得する経路を塞ぎます。Debian/Ubuntuでは以下のkernelパラメーターが該当します。

echo "kernel.unprivileged_userns_clone=0" | sudo tee /etc/sysctl.d/99-userns.conf
sudo sysctl --system

この措置によりDirtyCloneを含むDirtyFragファミリー全般の悪用前提が崩れます。ただし、rootlessコンテナ、Podman/Buildahのrootlessモード、一部のCIサンドボックス、Chromiumのsandboxed browserなどがこの設定によって動作しなくなります。本番環境への適用前に、依存するアプリケーションへの影響評価が必要です。

2. IPsec関連モジュールをブロックする

esp4、esp6、rxrpcといったin-place復号プリミティブを持つカーネルモジュールのロードを禁止することで、攻撃の書き込みプリミティブそのものを塞ぐ手があります。ただしIPsec(VPN)機能とAFSサポートが利用できなくなるため、これらの機能を本番で利用している環境では適用できません。また、カーネルにbuilt-inでコンパイルされている場合は、modprobeレベルでのblacklistは効果がない点にも注意が必要です。

3. drop_cachesは事後対処として限定的

echo 3 > /proc/sys/vm/drop_cachesでページキャッシュを破棄すれば、改変されたキャッシュページは消去できます。ただしすでに攻撃者がroot権限のシェルを取得した後では、シェル自体は残ったままで意味がありません。汚染の疑いがあるホストは、ホスト全体が侵害された前提で扱うのが堅実です。

優先対処すべき環境

JFrogが特に高リスクと整理しているのは、以下のようなマルチテナント・コンテナ型の環境です。いずれも信頼できないローカルユーザーやワークロードが共存し、ローカル権限昇格がそのまま全テナント・全ジョブの侵害につながる構造を持っています。

マルチテナントクラウド環境：共有Linuxホストに複数の顧客のアカウントが共存する構成
Kubernetesクラスタ：特に非特権user namespacesが有効化されたノード、信頼できないコンテナイメージを許容するクラスタ
コンテナ化ワークロード：privilegedコンテナが配置される環境、もしくはrootlessコンテナのために非特権user namespacesに依存している環境
CI/CDランナー：プルリクエストのテストジョブなど、信頼できないコードを実行する可能性のあるランナー

DirtyFragクラスは「終わっていない」

JFrogが論考の結びで強調しているのは、DirtyFragクラスの脆弱性が単一の関数の不具合ではなく、Linuxカーネルのzero-copy networkingという設計全体に関わる「契約問題」だという点です。skbフラグメントを移動するすべての処理経路は、shared-fragビットを毎回正しく伝播させる責任を負います。性能最適化のためにファイルに裏打ちされたメモリをパケットデータとして使える設計を維持する以上、どこか1箇所でフラグが落ちれば、それがそのまま書き込みプリミティブに転化する構造です。

DirtyClone自体は__pskb_copy_fclone()とskb_shift()の経路を中心に修正されますが、JFrogは「DirtyFragクラスはおそらく終わっていない」と整理しています。skb_shinfo()->flagsのSKBFL_SHARED_FRAGに触れるすべてのfrag-transfer経路が、新たなCVEの候補になり得るためです。本シリーズの総論記事として、ページキャッシュ汚染型LPEの系譜全体(Dirty COW、Dirty Pipe、Copy Fail、pedit COW、DirtyFragファミリー)を整理した記事を別途まとめる予定です。

対処手順

本稿執筆時点でJFrogによるエクスプロイトのウォークスルーが公開されており、共有ホスト、CI/CDランナー、Kubernetesノードなどを運用している組織は速やかな対応が望まれます。優先順を整理すると以下の通りです。

カーネル更新と再起動：ディストリビューション提供のカーネル更新を適用し、再起動する。DirtyFragファミリーの一連のCVE(CVE-2026-43284、CVE-2026-43500、CVE-2026-46300、CVE-2026-43503)すべてに対応した版に更新できているかを確認する
即時パッチが難しい場合の緩和策適用：非特権user namespacesの無効化を業務要件に照らして検討する。IPsec機能を利用していない環境であれば、esp4/esp6モジュールのblacklist化も選択肢となる
優先環境の特定：マルチテナントクラウド、Kubernetesノード、CI/CDランナー、コンテナ化ワークロードを先にパッチする
運用ログの点検：2026年5月以降のホスト状態について、不審なnamespace生成、XFRM/IPsec関連の設定変更、loopback経由の異常通信の組み合わせなど、JFrogが示した攻撃チェーンに類似する操作のログ痕跡を確認する
侵害疑い時のホスト再構築：痕跡が残りにくい攻撃である以上、状況証拠で侵害が疑われる場合はホスト全体を侵害済みとして再構築するのが安全

一次情報・公式情報

参考情報

slug: linux-dirtyclone-cve-2026-43503-lpe