2026年6月16日、Linuxカーネルに新たなローカル権限昇格（local privilege escalation） の脆弱性 CVE-2026-46331 が公開されました。通称「Pedit COW（ペディット・カウ）」。カーネルのトラフィック制御（traffic control, tc）サブシステムである net/sched の欠陥を突き、ローカルの非特権ユーザーが管理者権限（root）を奪取できるという、サーバー運用者にとって看過できない問題です。

さらに厄介なことに、この脆弱性の実証コード（PoC）はCVE割り当てからわずか1日で公開されました。攻撃手法が広く知れ渡った今、影響を受けるシステムの管理者は、速やかな対応が求められています。Ubuntuは深刻度を「High」、Red Hatは「Important」と評価し、RHEL 8/9/10やUbuntuの広範なバージョンが影響を受けます。

本記事は、このCVE-2026-46331「Pedit COW」について、何が問題なのか・どう悪用されるのか・どのシステムが影響を受け・どう対策するのかを、防御側（システム管理者・セキュリティ担当）の視点から、一次情報をもとに整理する解説記事です。攻撃を再現するための手順書ではなく、脅威を正しく理解して自分のシステムを守ることを目的としています。脆弱性の仕組みを理解することは、闇雲に「危ない」と恐れるのではなく、自分の環境のどこにリスクがあり、何を優先して塞ぐべきかを冷静に判断するための、防御の第一歩です。

⚠️ まず結論：対策

影響を受けるのは古い（未パッチの）Linuxカーネルです。各ディストリビューションが配布するカーネルのセキュリティアップデートを適用し、再起動することが根本対策です。即時にパッチ適用できない場合の緩和策（後述）として、非特権ユーザー名前空間の無効化や act_pedit モジュールのブロックリスト化が有効です。まずは自社のカーネルバージョンが対策済みか確認してください。

1. CVE-2026-46331「Pedit COW」とは

CVE-2026-46331は、Linuxカーネルの公式な修正コミットでは次のように説明されています。

net/sched: fix pedit partial COW leading to page cache corruption（peditの部分的なCOWがページキャッシュ破損を引き起こす問題の修正）

要点を平易に言い換えると、こうです。Linuxには tc（トラフィック制御）という、ネットワークパケットを整形・制御する強力な機能があり、その中の pedit（packet edit） というアクションは、通過するパケットの中身を書き換えることができます。このパケット書き換えの際に、カーネルが書き込み対象メモリを安全に複製する処理（COW: Copy-On-Write）の範囲計算を誤ることで、本来書き換えてはいけないメモリ領域（ページキャッシュ）まで汚染できてしまう——これがPedit COWの本質です。

「Pedit COW」という通称は、過去に著名だったLinuxカーネルの権限昇格脆弱性 Dirty COW（CVE-2016-5195） を彷彿とさせます。Dirty COWもCopy-On-Writeの競合状態を突いてroot権限を奪う攻撃でした。今回のPedit COWは仕組みこそ異なりますが、「COWの不備を突いて、本来書き込めないものを書き込む」という構図が共通しており、その連想からこの名がついています。Dirty COWが当時、世界中のLinuxサーバーに緊急パッチ対応を迫った歴史を思えば、同系統の通称がつけられたこと自体が、この脆弱性の深刻度に対する研究者コミュニティの受け止めを物語っています。

・CVE番号：CVE-2026-46331
・通称：Pedit COW
・種別：ローカル権限昇格（非特権ユーザー → root）
・影響箇所：Linuxカーネル net/sched（act_pedit）
・公開日：2026年6月16日
・深刻度：Ubuntu「High」／Red Hat「Important」
・PoC：公開済み（CVE割り当ての翌日に公開）

2. 技術的な根本原因 — 部分COWの抜け穴

もう少し技術的に踏み込みます。カーネルの修正内容から、バグの正体が明確に分かります。

問題のあった関数 tcf_pedit_act() は、パケットを書き換える前に「これから書き込む範囲」を計算し、skb_ensure_writable() を呼んでその範囲を書き込み可能な状態（＝COWで複製した自前のコピー）にします。ところが、このCOW範囲の計算が、キー処理のループの「前」に一度だけ行われていました。計算には tcfp_off_max_hint（書き込みオフセットの最大値のヒント）が使われますが、このヒントは、typed key（型付きキー）が実行時に加える「ヘッダオフセット」を考慮していなかったのです。

その結果、何が起きるか。実際の書き込みは、ヒントが想定したより後ろのアドレスに及ぶことがあります。すると、書き込み領域の一部がCOWされないまま（un-COW’d）になり、複製されていない共有メモリ——具体的にはページキャッシュ——を直接書き換えてしまうのです。

COW（Copy-On-Write）と、その「抜け」が危険な理由

COWは「書き込みが発生する瞬間に初めてコピーを作る」省メモリの仕組みです。複数のプロセスが同じメモリ（たとえばディスク上のファイルのキャッシュ）を共有していても、誰かが書き換えようとした時点で、その人専用のコピーが作られ、他者には影響しません。このコピーが正しく作られないと、書き換えが「共有された元データ」に直接及び、他のプロセス（や、ディスク上のファイルのキャッシュ表現）を汚染してしまいます。Pedit COWは、まさにこの「コピーの作り漏れ」を突いています。

カーネルの修正は、この設計上の穴を以下のように塞いでいます。

・skb_ensure_writable() をキーごとのループの「内側」へ移動し、実際の書き込みオフセットが判明した時点でCOWする
・オフセット計算にオーバーフローチェックを追加
・負のオフセット（ingressでのEthernetヘッダ編集など）には skb_cow() でヘッドルームをCOWする
・offset_valid() を INT_MIN から保護（負号反転が未定義動作になるのを防ぐ）

つまり「範囲を一度だけ大ざっぱに見積もる」のをやめ、「実際に書き込む直前に、正確な範囲をCOWする」という、より堅実な実装に修正されたわけです。

バグの本質：COW範囲を「いつ」計算するか 修正前（脆弱） ① ループ前に範囲を一度だけ計算 (tcfp_off_max_hint を使用) ② 型付きキーのオフセットを 考慮していない → 一部が未COWのまま書き込み 修正後（安全） ① skb_ensure_writable() を キーごとのループ内へ移動 ② 実際の書込オフセットで COW＋オーバーフロー検査 → 書込領域が必ずCOWされる
COW範囲を「ループ前に一度だけ」計算していたのが原因。修正後は「実際に書き込む直前」に正確な範囲をCOWする（出典: Ubuntu Security / カーネル修正コミットをもとに作図）

3. どう悪用されるのか — ページキャッシュ汚染という手口

このバグが恐ろしいのは、ディスク上のファイルに一切触れずに、root権限を奪える点にあります。報じられている悪用手法（概念レベル）を整理します。攻撃の核心は、setuid root バイナリのページキャッシュを汚染することです。

/bin/su のような setuidビット付きのバイナリは、一般ユーザーが実行しても一時的にroot権限で動く特別なプログラムです。これらは一度実行されるとメモリ上のページキャッシュにキャッシュされます。攻撃者は、Pedit COWを使ってこのキャッシュされた /bin/su のメモリ表現を書き換え、小さな悪意あるコードを注入します。そして、その「汚染された /bin/su」を実行すると、注入したコードがroot権限で動く——という流れです。

flowchart TD A["非特権ユーザー"] --> B["ユーザー名前空間を作成
名前空間内で CAP_NET_ADMIN を取得"] B --> C["tc / act_pedit でパケット編集を構成"] C --> D["部分COWの欠陥を発動
(CVE-2026-46331)"] D --> E["ページキャッシュ上の
setuidバイナリ(/bin/su)を汚染"] E --> F["汚染されたバイナリを実行"] F --> G["注入コードが
root権限で動作"] style D fill:#3a1414,color:#fecaca style G fill:#3a1414,color:#fecaca

重要なのは、ファイルそのものはディスク上では無傷だということです。改ざんされるのはメモリ上のキャッシュ表現だけなので、ファイルのハッシュ値を比較するような従来の改ざん検知では気づきにくい、という厄介さがあります。攻撃が成功した痕跡はメモリ上にしか残らず、システムを再起動すればページキャッシュは消えて元のクリーンなバイナリが読み直されるため、フォレンジック（事後調査）の観点でも追跡が難しくなります。「ディスクを汚さない」という性質は、攻撃者にとってのステルス性そのものなのです。

この「ページキャッシュ汚染による権限昇格」という攻撃クラスは、Dirty COW以来、Linuxセキュリティ研究者が繰り返し注目してきたテーマです。共有メモリ（ページキャッシュ）を介して特権プロセスの実行イメージに干渉できれば、カーネルの奥深くを直接いじらずとも、setuidバイナリという「正規のroot昇格の入口」を乗っ取れてしまう。Pedit COWは、その古典的な攻撃モデルが、net/schedという別の経路から再び現実になった事例と言えます。

ただし、攻撃には前提条件があります。これは緩和策を考えるうえで重要です。

・act_pedit モジュールがロード可能であること（tc のpeditアクションが使える）
・非特権ユーザー名前空間（unprivileged user namespaces）が有効であること——これにより、攻撃者は名前空間内に限定された CAP_NET_ADMIN（ネットワーク管理権限）を取得し、バグの発動に必要な操作を行える

逆に言えば、これらの前提を断つことが、パッチ適用までの時間を稼ぐ緩和策になります。

この「非特権ユーザー名前空間」というのは、近年のLinuxにおける権限昇格脆弱性の常連の足がかりです。本来は、コンテナやブラウザのサンドボックスといった正当な機能のために導入されたものですが、非特権ユーザーが名前空間内で擬似的に各種の権限（ここでは CAP_NET_ADMIN）を持てるため、結果としてカーネルの広い攻撃面——tc を含むネットワーク機能など——に、一般ユーザーが手を伸ばせる窓口になってしまいます。Pedit COWも、この窓口を通じて act_pedit に到達することで成立します。利便性と攻撃面はしばしばトレードオフであり、この脆弱性はその典型例と言えるでしょう。

4. 影響範囲 — どのシステムが危険か

CVE-2026-46331は、脆弱な（未修正の）Linuxカーネルを使うシステム全般に影響します。主要ディストリビューションの評価を整理します。

ベンダー 深刻度評価 影響範囲
Ubuntu High 20.04 / 22.04 / 24.04 / 25.10 / 26.04 など広範に「Vulnerable」
Red Hat Important RHEL 8 / 9 / 10 が影響対象
上流（kernel.org） — 修正コミットがメインラインにマージ済み

CVSSの観点では、攻撃元はローカル（local）、必要な権限は低（Low、＝一般ユーザーで可）、ユーザー操作は不要（None）、そして成功時の機密性・完全性・可用性への影響は高い——という、典型的な深刻なローカル権限昇格のプロファイルを示しています。リモートから直接突かれるものではありませんが、いったん一般ユーザー権限で侵入された後の「権限昇格の踏み台」として極めて危険です。現実の侵害は、単一の脆弱性だけで完結することは稀で、「リモートのアプリ脆弱性で一般ユーザー権限を取得 → ローカル権限昇格でroot奪取 → 永続化」という連鎖で深刻化します。Pedit COWは、その連鎖の中盤を一気に進めてしまう、強力な部品になり得るのです。

特に注意すべきは、次のような環境です。

・マルチユーザーのサーバー：複数の一般ユーザーがログインする共用サーバーでは、内部の一般ユーザーがrootを奪える
・コンテナホスト：コンテナからのブレイクアウトと組み合わさると影響が拡大しうる
・Webアプリ等が同居するサーバー：アプリの脆弱性で一般ユーザー権限を取られた後、このCVEでrootへ昇格される多段攻撃のリスク
・非特権ユーザー名前空間を有効にしている環境：攻撃の前提が揃いやすい

5. 対策と緩和策 — いま管理者がやるべきこと

防御側として取るべき行動を、優先度順に整理します。

第一に、カーネルのパッチ適用（根本対策）。最も確実なのは、ディストリビューションが提供する修正済みカーネルへのアップデートと再起動です。

# Ubuntu / Debian系
sudo apt update && sudo apt upgrade
sudo reboot

# RHEL / CentOS / Rocky / Alma系
sudo dnf update kernel
sudo reboot

再起動が前提になるため、無停止が求められる本番環境では、カーネルライブパッチ（Ubuntu Livepatch、Red Hat kpatch、KernelCare等）の活用も選択肢になります。これらは再起動なしにカーネルの修正を適用できます。ただしライブパッチは万能ではなく、対応する修正がベンダーから提供されるまでのタイムラグや、適用可能な変更の種類に制限がある場合もあります。あくまで「再起動のメンテナンス枠を確保するまでの橋渡し」と位置づけ、計画的な再起動による正式なパッチ適用も並行して進めるのが堅実です。

第二に、即時パッチ不可の場合の緩和策。メンテナンス枠がすぐ取れない場合、攻撃の前提条件を断つことで、リスクを大幅に下げられます。

・非特権ユーザー名前空間を無効化する（攻撃に必要な名前空間内 CAP_NET_ADMIN の取得を阻む）

# 非特権ユーザー名前空間を無効化（Debian/Ubuntu系の例）
sudo sysctl -w kernel.unprivileged_userns_clone=0
# 恒久化する場合は /etc/sysctl.d/ に設定を追記

・act_pedit モジュールのロードをブロックリスト化する（peditアクション自体を使えなくする）

# act_pedit のロードを禁止（モジュールを使っていない環境向け）
echo "install act_pedit /bin/true" | sudo tee /etc/modprobe.d/disable-act_pedit.conf
緩和策の前に確認を

これらの緩和策は副作用を伴う可能性があります。非特権ユーザー名前空間は一部のコンテナランタイムやブラウザのサンドボックスが利用しているため、無効化すると正常な機能に影響することがあります。act_pedit も、`tc` で高度なパケット編集を行っている環境では必要な場合があります。本番適用前に、自環境での依存有無を必ず検証してください。緩和策はあくまで「パッチ適用までの時間稼ぎ」であり、根本対策はカーネル更新です。

第三に、検知と監査。この攻撃はファイルのディスク上の実体を変えないため、ハッシュ比較型の改ざん検知では捕捉しにくい特性があります。act_pedit の予期しないロード、見慣れないユーザー名前空間の作成、tc の異常な使用といった挙動ベースの監視が、検知の手がかりになります。具体的には、auditd でモジュールのロード（init_module/finit_module）や unshare/clone 系のシステムコールを記録する、lsmod で見慣れない act_pedit のロードを定期確認する、といった運用が考えられます。EDR（Endpoint Detection and Response）製品を導入している環境では、非特権プロセスが短時間にネットワーク管理権限を取得し tc を操作する、という一連の振る舞いを異常として検知できる場合があります。

第四に、最小権限の徹底。そもそもローカル権限昇格は「攻撃者が一般ユーザー権限を取得済み」であることが前提です。したがって、Webアプリやサービスを必要最小限の権限で動かす、不要なローカルアカウントを作らない、SSHアクセスを厳格に管理するといった基本的な防御の積み重ねが、権限昇格の「前段階」を断つうえで効いてきます。多層防御の発想で、入口（侵入）と昇格の両方に手を打つことが重要です。

6. なぜAIメディアがLinux CVEを扱うのか

当サイトはAI関連OSSの解説を主軸にしていますが、本記事のようなLinuxカーネルの重大脆弱性も、当サイトの読者にとって無関係ではありません。理由は明確です。

第一に、AIワークロードは、ほぼすべてLinuxサーバー上で動いているからです。LLMの学習・推論、AIエージェントの実行基盤、ベクトルデータベース——これらの大半はLinux上に構築されています。そのカーネルにroot奪取の穴があれば、AIシステムの土台そのものが脅かされます。とりわけ、複数の顧客やジョブが同居するAI向けの共用GPUサーバーでは、ローカル権限昇格は深刻な意味を持ちます。

第二に、AIエージェントが任意コードを実行する時代だからです。コードを書き、シェルコマンドを実行するAIエージェントが普及するなか、もしエージェントの実行環境が侵害された場合、このCVEのようなローカル権限昇格が「サンドボックスからの脱出＋root奪取」の連鎖の一部になりえます。AIの安全な運用は、その下で動くOSの堅牢さと不可分なのです。

第三に、Linuxカーネルは世界最大級のオープンソースプロジェクトであり、その脆弱性対応のプロセス（迅速なコミット、各ディストリの評価、CVE公開）は、OSSセキュリティの教科書的な事例でもあります。今回も、上流での修正コミット、Ubuntu・Red Hatによる迅速な深刻度評価、そしてCVEとしての公開——という一連の流れが、わずか数日のうちに進みました。同時に、PoCが即日公開されたことは、現代の脆弱性が「公開と悪用がほぼ同時」に進むことを改めて示しています。守る側にとって、パッチ公開を悠長に待つ余裕はなくなりつつあるのです。この「攻撃者と防御者の時間差の消失」こそ、AI時代を含む今後のセキュリティ運用が向き合う最大の課題のひとつです。

まとめ：仕組みを理解し、速やかにパッチを

CVE-2026-46331「Pedit COW」は、Linuxカーネル net/sched の部分COW欠陥を突き、ローカルの非特権ユーザーがページキャッシュ上のsetuidバイナリを汚染してrootを奪取できる、深刻なローカル権限昇格脆弱性です。PoCが即日公開されており、影響範囲はRHELやUbuntuの広範なバージョンに及びます。対策はカーネルのアップデートと再起動が根本で、即時対応できない場合は非特権ユーザー名前空間の無効化や act_pedit のブロックが緩和策になります。AIワークロードの土台であるLinuxの堅牢性は、AI時代のセキュリティの前提条件です。まずは自環境のカーネルが対策済みか、今すぐ確認してください。

よくある質問（FAQ）

Q1. CVE-2026-46331「Pedit COW」とは何ですか? Linuxカーネルのトラフィック制御サブシステム net/sched（act_pedit）にある脆弱性です。パケット編集時のCopy-On-Write（COW）範囲計算の誤りで、本来書き換えてはいけないページキャッシュを汚染でき、ローカルの非特権ユーザーがroot権限を奪取できます。2026年6月16日に公開されました。

Q2. リモートから攻撃されますか? いいえ、これはローカル権限昇格の脆弱性です。攻撃者がまず一般ユーザーとしてシステムにアクセスできることが前提です。ただし、別の脆弱性で一般ユーザー権限を取られた後の「root昇格の踏み台」として悪用される多段攻撃のリスクがあり、軽視はできません。

Q3. 自分のシステムは影響を受けますか? 未修正のLinuxカーネルを使っていれば影響を受ける可能性があります。Ubuntu（20.04〜26.04など）やRHEL 8/9/10が影響対象として挙げられています。各ディストリビューションのセキュリティ情報で、自分のカーネルバージョンが対策済みかを確認してください。

Q4. どう対策すればよいですか? 根本対策は、ディストリビューションが配布する修正済みカーネルへのアップデートと再起動です。無停止が必要ならカーネルライブパッチを検討します。即時パッチが難しい場合は、非特権ユーザー名前空間の無効化や act_pedit モジュールのブロックリスト化が緩和策になります（副作用の確認が必要）。

Q5. PoC（実証コード）は出回っているのですか? はい。報道によれば、CVE割り当ての翌日には公開された概念実証（PoC）が存在します。攻撃手法が広く知られている状態のため、対応の緊急度は高いと考えるべきです。本記事は防御目的の解説であり、悪用手順は提供しません。

Q6. 「Dirty COW」と同じものですか? 別物です。2016年のDirty COW（CVE-2016-5195）もCopy-On-Writeの不備を突くroot昇格でしたが、対象の仕組みは異なります。今回のPedit COWは net/sched の pedit における部分COWの漏れが原因で、「COWの不備でroot昇格」という構図の類似から、その通称がつけられています。

参照ソース

・CVE-2026-46331 Detail（NVD） — 米国国立脆弱性データベースの公式エントリ
・CVE-2026-46331（Ubuntu Security） — Ubuntuの深刻度評価（High）と影響パッケージ・修正状況
・New Linux pedit COW Exploit Enables Root Access by Poisoning Cached Binaries（The Hacker News） — 悪用手法とタイムラインの報道
・pedit-cow (CVE-2026-46331): Linux tc Flaw Grants Root（TuxCare） — 技術解説と緩和策