DirtyClone CVE-2026-43503｜Linux カーネル特権昇格の影響確認と暫定回避

はじめに

2026 年 6 月 25 日、JFrog Security Research が Linux カーネルの新たなローカル特権昇格（LPE）脆弱性 DirtyClone（CVE-2026-43503）の実証解説を公開しました。DirtyClone は、4 月末以降に立て続けに公開された DirtyFrag ファミリーの 4 件目にあたり、これまでの CopyFail・Dirty Frag・Fragnesia と同じ「ファイルに紐づくページキャッシュを、ネットワークバッファとして書き換える」という共通の本質を持ちます。

すでに Dirty Frag や Fragnesia への対応を済ませた管理者にとっての関心事は、「既存の対応でこれは防げているのか」「自社環境は影響を受けるのか」「すぐにカーネルを更新できない場合の暫定回避は何か」の 3 点に集約されます。本記事はこの観点に絞って整理します。

恒久対処は修正済みカーネル（Linux v7.1-rc5 相当、または各ディストリのバックポート）への更新です。DirtyClone の悪用には CAP_NET_ADMIN が必要で、これは未特権 user namespace の作成を通じて獲得される設計のため、攻撃前提を断つうえで namespace 作成の制限が暫定回避の軸になります。攻撃はディスク上のファイルを書き換えず、メモリ上のページキャッシュのみを改ざんするため、ファイル整合性チェックでは検知が難しい点も従来と共通します。

DirtyClone（CVE-2026-43503）の概要と DirtyFrag ファミリーでの位置づけ

DirtyClone は、Linux カーネルがネットワークパケットを内部的にクローン（複製）する処理で、ページキャッシュとの共有を示す安全フラグが失われることに起因する LPE 脆弱性です。低権限のローカルユーザーが、読み取り専用の特権バイナリ（/usr/bin/su など）のページキャッシュを書き換えて root 権限を取得し得ます。Red Hat 系での評価は本記事執筆時点で追跡中ですが、CVSS は 8.8（High）とされています。

JFrog はこの脆弱性について、単一のコードパスに限定されない攻撃手法である点を強調しています。

参考: JFrog Security Research – Dissecting and Exploiting Linux LPE Variant: DirtyClone (CVE-2026-43503)
“the underlying attack primitive is not limited to a single vulnerable code path”
（その根底にある攻撃プリミティブは、単一の脆弱なコードパスに限定されない）
https://research.jfrog.com/post/dissecting-and-exploiting-linux-lpe-variant-dirtyclone-cve-2026-43503/

DirtyFrag ファミリー 4 件の整理

DirtyClone は、2026 年 4 月末から約 2 か月の間に公開された一連の脆弱性の最新版です。いずれも「カーネルが排他所有していない、ファイル由来のページに対して書き込み処理が走ってしまう」という同じ失敗パターンを共有します。

DirtyFrag / Fragnesia / DirtyClone は、厳密には 1 本の攻撃を構成する「チェーン」ではなく、同じ攻撃プリミティブを共有する別経路の「兄弟（variant）」の関係にあります。各修正が 1 つのコードパスを塞ぐたびに、フラグを落とす別の経路が見つかってきた、という流れです。Fragnesia の技術的背景や Dirty Frag との違いについては、関連記事『Fragnesia CVE-2026-46300｜Linux カーネル特権昇格と Dirty Frag との違い』で詳しく整理しています。

なお CVE-2026-43503 のタイムラインは、5 月 16 日に元 DirtyFrag 研究者 Hyunwoo Kim 氏が複数箇所にまたがる修正を提出、5 月 21 日に mainline へマージ（フラグ伝播を担う 48f6a5356a33 ほか一連のコミット）、5 月 23 日に CVE 採番、5 月 24 日リリースの Linux v7.1-rc5 が最初の修正タグ、という経緯です。修正は特定の関数だけでなく、skb のコピー・クローン・結合・GRO 受信・セグメント化といった各経路で SKBFL_SHARED_FRAG が保持されるよう、クラス全体に対して適用されています。

「DirtyClone」と「Fragnesia」という呼称の整理

呼称の混乱が起きやすいため、先に整理します。Ubuntu は CVE-2026-43503 を「Fragnesia」の一部として追跡しており、JFrog は同じ CVE を悪用する exploit を「DirtyClone」と命名しています。 つまり両者は同一の CVE-2026-43503 を異なる視点から呼んだものです。本記事では、CVE 番号（CVE-2026-43503）を基準に、JFrog の命名である DirtyClone を見出しに用います。自社のディストリのアドバイザリを確認する際は、「DirtyClone」という名称が載っていなくても、CVE-2026-43503（あるいは Fragnesia 関連の追加修正）として記載されている場合がある点に留意してください。

攻撃の仕組み（packet clone 時のフラグ消失）

DirtyClone の本質は、ファミリー共通の「ファイル由来ページの誤った in-place 書き込み」です。ここでは、暫定回避がなぜ効くのかを理解するために必要な範囲で、仕組みの概要のみを整理します（具体的な悪用手順は扱いません）。

カーネルの zero-copy ネットワーク機能では、ファイルのページキャッシュがそのままネットワークパケットのデータ（skb のフラグメント）として参照されることがあります。このとき、当該ページが「ファイルと共有されており、書き込みで上書きしてはいけない」ことを示すのが SKBFL_SHARED_FRAG フラグです。このフラグが立っていれば、IPsec の復号処理はページを直接書き換えず、先にコピー（Copy-on-Write）してから復号します。

DirtyClone では、カーネルがパケットを内部的にクローンする際に呼ばれる __pskb_copy_fclone()（および skb_shift()）が、このフラグの伝播に失敗します。結果として、本来「共有ページ」として保護されるべきページが「安全に書き込めるページ」として扱われ、攻撃者が制御するループバック IPsec トンネルの復号処理によって、ページキャッシュ上のバイトが書き換えられます。JFrog の解説では、パケットを内部的に複製する netfilter の TEE ターゲットが、このクローン経路のトリガーとして用いられています。

問題は単一の関数の不具合ではなく、契約（コントラクト）の問題である、と整理されています。

参考: The Hacker News – New DirtyClone Linux Kernel Flaw Lets Local Users Gain Root via Cloned Packets
“every code path that moves skb fragments has to preserve the shared-frag bit”
（skb フラグメントを移動させるすべてのコードパスが、shared-frag ビットを保持しなければならない）
https://thehackernews.com/2026/06/new-dirtyclone-linux-kernel-flaw-lets.html

攻撃の成立には、IPsec トンネルを構成するための CAP_NET_ADMIN が必要です。Debian や Fedora のように未特権ユーザーが user namespace を作成できる環境では、新しい namespace の内部でこの権限を得られるため、一般ユーザーでも攻撃前提が整います。この「namespace 作成 → CAP_NET_ADMIN 獲得」という入口が、暫定回避で namespace 作成を制限する根拠になります。

書き換えはメモリ上のページキャッシュに対してのみ行われ、ディスク上のファイルは変更されません。そのため rpm -V や debsums -c などのファイル整合性チェックでは検知が難しく、再起動するとページキャッシュが再読み込みされて元のバイナリに戻る、という挙動も従来のファミリーと共通します。

影響を受けるか確認する（ディストリ別チェック）

DirtyClone への該当判定は、次の 3 つを順に確認するのが実務的です。すなわち、カーネルが修正版より前か、未特権ユーザーが user namespace を作成できるか（＝攻撃前提の CAP_NET_ADMIN を得られるか）、そして IPsec 関連モジュールがロードされ得るか、の 3 点です。

カーネルバージョンの確認

まず稼働中のカーネルが修正を取り込んでいるかを確認します。mainline の修正は Linux v7.1-rc5（コミット 48f6a5356a33）で初めてタグ付けされ、各ディストリの stable / LTS にバックポートされています。

$ uname -r

出力されたバージョンが、利用中ディストリの修正版以降であれば対処済みです。主なディストリの修正版は次のとおりです（執筆時点で確認できたもの）。

参考: Debian Security Advisory DSA-6295-1
“these problems have been fixed in version 6.12.90-1”
（これらの問題はバージョン 6.12.90-1 で修正されています）
https://security-tracker.debian.org/tracker/CVE-2026-43503

クラウド向け・リアルタイム・OEM など generic 以外のカーネルを使っている場合は、generic の情報をそのまま当てはめず、該当パッケージのアドバイザリを個別に確認することが推奨されます。

未特権 user namespace を作成できるかの確認

DirtyClone の既定の攻撃経路は、未特権ユーザーが user namespace を作成して内部で CAP_NET_ADMIN を得るところから始まります。この入口が塞がれていれば、未パッチでも既定の PoC 経路は成立しません。 現在の状態は次のコマンドで確認できます。sysctl 名はディストリで異なります。

# Debian / Ubuntu 系（1=作成可、0=不可）
$ cat /proc/sys/kernel/unprivileged_userns_clone

# RHEL / Rocky / AlmaLinux / Fedora 系（0=作成不可）
$ cat /proc/sys/user/max_user_namespaces

より直接的には、一般ユーザーで実際に user namespace を作成できるかを試す方法があります。

$ unshare --user --map-root-user id

このコマンドが uid=0(root) を含む出力で成功する場合、未特権ユーザーが user namespace を作成できる状態であり、攻撃前提が成立し得ます。Operation not permitted で失敗する場合は、その経路は制限されています。

ディストリの既定値は次の傾向です。Debian と Fedora は既定で未特権 user namespace の作成が有効です。Ubuntu は 24.04 LTS 以降、AppArmor によって未特権ユーザーの namespace 作成を制限しており、既定の攻撃経路はブロックされますが、ディストリのトラッカー上は引き続き affected として扱われています。

IPsec 関連モジュールのロード状態の確認

DirtyClone は、復号処理を行う IPsec ESP 経路（esp4 / esp6）を改ざんの実行段として利用します。これらのロード状態は次で確認できます。

$ lsmod | grep -E '^(esp4|esp6|rxrpc)'

何も表示されない場合は現時点で未ロードですが、カーネルの自動ロード機構によって後からロードされ得る点には注意が必要です（このため、後述のブラックリスト化は blacklist 行ではなく install ... /bin/false 形式が推奨されます）。

ディストリ別の影響早見

上記を踏まえた、ディストリ別の影響傾向の早見表です。「既定経路の成否」は、JFrog が示した未特権 user namespace 経由の既定 PoC が成立し得るかを示します。

Amazon Linux については注意が必要です。先行する Fragnesia（CVE-2026-46300）では、Amazon Linux と Bottlerocket は ESP-in-TCP の espintcp モジュールを提供しないため影響対象外とされていました。しかし DirtyClone の経路は espintcp ではなく、__pskb_copy_fclone() による packet clone と通常の IPsec ESP（esp4 / esp6）であるため、Fragnesia の「対象外」という結論がそのまま当てはまるとは限りません。 Amazon Linux の該当有無は、AWS Security Bulletin で CVE-2026-43503 の項を個別に確認することが推奨されます。

パッチを当てられない場合の暫定回避

恒久対処は修正済みカーネルへの更新と再起動です。ここでは、すぐに更新できない場合に攻撃面を縮小する暫定回避を整理します。いずれも一時的な緩和であり、恒久対処の代替にはなりません。 メンテナンスウィンドウでのカーネル更新を前提に、それまでの保護として位置づけてください。

暫定回避 1: 未特権 user namespace の作成制限

DirtyClone の既定経路は user namespace の作成に依存するため、これを禁止すると既定の攻撃前提を断てます。sysctl 名がディストリで異なる点に注意してください。

# Debian / Ubuntu 系
$ echo "kernel.unprivileged_userns_clone = 0" | sudo tee /etc/sysctl.d/99-userns-hardening.conf

# RHEL / Rocky / AlmaLinux / Fedora 系
$ echo "user.max_user_namespaces = 0" | sudo tee -a /etc/sysctl.d/99-userns-hardening.conf

$ sudo sysctl --system

Ubuntu では両方の sysctl が存在し得るため、kernel.unprivileged_userns_clone=0 のみでは経路が残る場合があります。確実を期すなら両方を設定します。あわせて、Ubuntu / Debian（kernel 6.1 以降）では AppArmor による制限も併用できます。

参考: systemshardening.com – Restricting Unprivileged User Namespaces
“On Ubuntu specifically, both settings may exist simultaneously.”
（Ubuntu では特に、両方の設定が同時に存在し得ます）
https://www.systemshardening.com/articles/linux/linux-unprivileged-namespace-restriction/

副作用として、ルートレスコンテナ（rootless Podman / Docker、Buildah）、一部の Flatpak アプリケーション、ブラウザーのサンドボックスなど、user namespace に依存する機能が動作しなくなります。root デーモンで動く通常の Docker は影響を受けません。ルートレスコンテナを運用している場合は、グローバルに無効化するのではなく、AppArmor で特定バイナリにのみ許可を与える方法も選択肢になります。

なお、この sysctl は既に user namespace 内で動作中のプロセスには効果が及びません。設定変更だけでなく、必要に応じて再起動を計画してください。

暫定回避 2: IPsec 関連モジュールのブラックリスト化

改ざんの実行段となる esp4 / esp6（および rxrpc）の読み込みをブロックすると、IPsec ESP を介した書き換え経路を塞げます。これは DirtyFrag ファミリー全体に共通する緩和で、Dirty Frag 対応として既に適用済みの環境では、追加操作なしに DirtyClone の ESP 経路も塞がれています。

$ sudo tee /etc/modprobe.d/dirtyfrag.conf >/dev/null <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

$ sudo modprobe -r esp4 esp6 rxrpc 2>/dev/null

この緩和は、対象機能がカーネル組み込み（built-in）ではなくローダブルモジュールである場合にのみ有効です。また、esp4 / esp6 の無効化は IPsec VPN を、rxrpc の無効化は AFS を停止させるため、IPsec ゲートウェイやトンネル終端として動作するホストでは適用前に利用有無の確認が必要です。設定ファイルの構文（install ... /bin/false）の意味、IPsec 利用環境での切り分け、アンロード失敗時の対処など、手順の詳細は関連記事『Dirty Frag CVE-2026-43284｜Linux カーネル特権昇格の緩和手順』で解説しています。

暫定回避 3: コンテナ・Kubernetes 環境での多層防御

DirtyClone で特にリスクが高いのは、信頼できないユーザーが namespace を作成し得るマルチテナントサーバー、CI ランナー、コンテナホスト、Kubernetes クラスターです。コンテナ環境では、ホスト OS 側のカーネル更新が根本対処であることを前提としつつ、Pod / コンテナレベルで以下を組み合わせると攻撃面を縮小できます。

具体的には、RuntimeDefault の seccomp プロファイルと Pod Security Standards の Restricted プロファイルの適用、CAP_NET_ADMIN をはじめとする不要な capability の剥奪、runAsNonRoot と allowPrivilegeEscalation: false の徹底です。これらは user namespace 作成や CAP_NET_ADMIN の獲得段階で攻撃チェーンを妨げる効果があります。

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

暫定回避適用後: ページキャッシュの退避

DirtyClone はメモリ上のページキャッシュのみを書き換え、ディスク上のファイルは変更しません。このため、緩和を適用しても、既に改ざんされたページキャッシュが残存している可能性があります。緩和適用後は、ページキャッシュをドロップして該当ページを退避させることが推奨されます。

$ sync
$ echo 3 | sudo tee /proc/sys/vm/drop_caches

ただし本番運用中の高 I/O ワークロードでは、実行直後に一時的なディスク I/O の増加が想定されます。メンテナンスウィンドウでの実施が無難です。drop_caches の各値の意味や、適用後の整合性確認・侵害痕跡（IoC）調査の観点も、前述の Dirty Frag の関連記事で詳しく扱っています。

既存の Dirty Frag / Fragnesia 対応で DirtyClone を防げるか

DirtyFrag ファミリーは同じ攻撃プリミティブを共有するため、過去の対応の一部は DirtyClone にもそのまま効きます。一方で、カーネルパッチは経路ごとに分かれており、過去のパッチだけでは塞ぎきれません。既存対応がどこまでカバーするかを整理します。

実務上のポイントは次の 2 点です。第 1 に、Dirty Frag 対応として esp4 / esp6 / rxrpc のブラックリスト化を適用済みなら、DirtyClone の ESP 経路は追加操作なしに塞がれています。 同様に、未特権 user namespace の作成を制限済みであれば、DirtyClone の既定経路（namespace 経由での CAP_NET_ADMIN 獲得）も断たれています。

第 2 に、カーネルパッチは経路ごとに分かれている点に注意が必要です。 DirtyFrag / Fragnesia / DirtyClone は兄弟（variant）の関係で、各修正が 1 つのコードパスを塞ぐたびに別の経路が見つかってきました。Dirty Frag や Fragnesia の修正だけを当てて DirtyClone（CVE-2026-43503）の修正を取り込んでいないカーネルは、依然として該当し得ます。恒久対処は、43503 の修正を含むカーネルへの更新です。

参考: JFrog Security Research – Dissecting and Exploiting Linux LPE Variant: DirtyClone (CVE-2026-43503)
“the attack primitive is not limited to a single vulnerable code path”
（その攻撃プリミティブは、単一の脆弱なコードパスに限定されない）
https://research.jfrog.com/post/dissecting-and-exploiting-linux-lpe-variant-dirtyclone-cve-2026-43503/

この性質から、DirtyFrag クラスは今後も新たな variant が見つかる可能性があります。skb のフラグメント記述子を移動させる処理で SKBFL_SHARED_FRAG フラグを保持し損ねる経路は、いずれも新たな CVE になり得るためです。短期的にはカーネル更新と暫定回避で対処しつつ、中期的には同系列のアドバイザリを継続的に追うことが推奨されます。

まとめ

DirtyClone（CVE-2026-43503）は、Linux カーネルが packet clone を行う際に SKBFL_SHARED_FRAG フラグを落とすことに起因するローカル特権昇格脆弱性です。DirtyFrag ファミリーの 4 件目で、JFrog が 6 月 25 日に実証解説を公開しました。恒久対処は修正済みカーネルへの更新ですが、すぐに更新できない環境では影響有無の確認と暫定回避が現実的な選択肢になります。本記事の要点を整理します。

• DirtyClone（CVE-2026-43503）は DirtyFrag ファミリー 4 件目の Linux 特権昇格脆弱性
• 根本原因は __pskb_copy_fclone() 等での SKBFL_SHARED_FRAG フラグ消失
• Ubuntu は本 CVE を Fragnesia、JFrog は DirtyClone として追跡する同一脆弱性
• 既定で影響を受けるのは未特権 user namespace が有効な Debian・Fedora 等
• 恒久対処は CVE-2026-43503 の修正を含むカーネルへの更新と再起動
• 暫定回避は user namespace 作成制限と esp4 / esp6 / rxrpc のブラックリスト化
• Dirty Frag 用 modprobe 緩和を適用済みなら DirtyClone の ESP 経路も遮断

以上、最後までお読みいただきありがとうございました。