LinuxカーネルtcサブシステムのローカルROOT昇格「pedit COW」（CVE-2026-46331）｜RHEL 8/9/10対象の攻撃機序とact_pedit無効化による緩和策

「ログインさえさせなければ安全」と考えていた方ほど、今回の話は落ち着いて読んでほしい内容です。すでに正規ユーザーとして入っている人や、Webアプリの小さな穴から一般権限のシェルを取った攻撃者が、そこから一気に管理者（root）まで上り詰められる――そんなLinuxカーネルのローカルROOT昇格の脆弱性が公表され、しかも実証コードまで出回っているからです。対象はRed Hat Enterprise Linux（RHEL）の8・9・10と広く、業務サーバーの多くが射程に入っています。

この脆弱性はCVE-2026-46331として登録され、通称「pedit COW」と呼ばれています。Linuxのトラフィック制御（tc＝traffic control、通信の流量や書き換えを制御する仕組み）の中の、act_peditという部品にある欠陥です。2026年6月16日にNVD（米国の脆弱性データベース）へ公開され、Red Hatは深刻度を「Important（重要）」と評価しています。

この記事では、CVE-2026-46331で何が起きているのかを一次情報から整理し、攻撃者がどの順序で一般権限からrootへ到達するのかを、防御のために攻撃者視点で分解します。そのうえで、自分のサーバーが該当するかの確認方法、攻撃の痕跡を見つける検知ポイント、そして修正カーネルの適用とact_peditの無効化を含む緩和策を、現場で使えるレベルで整理します。攻撃の流れに触れるのは、あくまで守りの設計のためです。敵がどこを通るかを知らなければ、塞ぐべき場所も見えてきません。正しく知って、優先順位をつけて対応していきましょう。

CVE-2026-46331「pedit COW」とは何が起きている脆弱性なのか

まず事実関係を一次情報ベースで整理します。CVE-2026-46331は、Linuxカーネルのネットワークスケジューラ（net/sched）に含まれるact_peditというトラフィック制御アクションに存在する脆弱性です。act_peditは、tcコマンドで通信パケットのヘッダを書き換えるために使われる正規の機能で、本来はネットワークの整形や中継の現場で役立つ部品です。その部品の内部処理に、書き込み範囲の確認漏れがありました。

NVDが公開した説明によれば、問題の核心はカーネル内部の関数tcf_pedit_act()の処理にあります。この関数は、書き換え対象のメモリを安全に複製してから編集するためのCOW（Copy-On-Write＝書き込み時に初めて複製を作る仕組み）の範囲を、キーごとの処理ループに入る前に一度だけ計算します。ところが、実行時に「typed key」と呼ばれる指定が加える追加のヘッダオフセット（書き換え位置のずれ）を、その範囲計算に含めていませんでした。結果として、本来は自分専用に複製しておくべきページを複製しないまま、共有されているページキャッシュ（ファイルの内容をメモリ上に保持しておく領域）へ書き込んでしまいます。これが「部分的なCOW」、すなわち通称の由来である「pedit COW」です。

この一文だけでは分かりにくいので、たとえで補足します。本来は「コピーを取ってから、そのコピーに落書きする」はずの処理が、コピーする範囲を狭く見積もったために、一部だけ「元の共有ファイルに直接落書きしてしまう」状態だと考えてください。共有ファイルに勝手な書き込みができるということは、その共有ファイルを使う他の利用者――場合によってはroot権限で動くプログラム――に、攻撃者の細工が届いてしまうことを意味します。

影響を受けるのは、Red Hat Enterprise Linux 8、9、10のすべてです。Red Hatのセキュリティ情報（RHSB-2026-008）で、この3系統が対象として明記されています。加えてRHEL for NVIDIAも対象とされ、OpenShift Container Platformについてはモジュールが既定で読み込まれないため影響度は低いと整理されています。深刻度はRed Hatの基準で「Important」。CVSS（脆弱性の深刻度を数値化したスコア）は公開時点ではまだ確定値が示されていないため、本記事では数値を断定せず、Red Hatの「Important」という評価を判断の基準とします。CVE番号や対象範囲の一次情報は、NVDのCVE-2026-46331ページとRed Hatのアドバイザリ（RHSB-2026-008）で確認できます。

なぜローカルの権限昇格が、これほど重く扱われるのか。リモートから直接侵入されるわけではないからと軽く見るのは早計です。現実の侵害は多段階で進みます。フィッシングやWebアプリの脆弱性で「一般ユーザー権限の足場」を取られた後、その足場からrootへ昇格できるかどうかが、被害が局所で済むか全体に広がるかの分かれ目になります。ローカル権限昇格は、攻撃者にとって「最後のひと押し」を与える部品です。だからこそ、外向きの守りを固めている組織ほど、内側の昇格経路を塞ぐ価値が高いと言えます。

攻撃者はどうやって一般権限からrootへ昇格するのか

ここからは、攻撃者がどの順で攻めてくるのかを、防御側が検知ポイントを設計するための材料として分解します。具体的な攻撃コードには立ち入らず、概念レベルで「どこを通って」rootに至るのかだけを押さえます。悪用の再現手順を示すことが目的ではありません。守るべき箇所を特定するための地図として読んでください。

1. 非特権ユーザー名前空間で擬似的な管理権限を手に入れる

出発点は、ユーザー名前空間（user namespace＝プロセスごとに独立した権限の見え方を作るLinuxの仕組み）です。多くのディストリビューションでは、一般ユーザーでも自分専用の名前空間を作れます。攻撃者はこれを使い、名前空間の内側だけで通用する管理権限のひとつ、CAP_NET_ADMIN（ネットワーク設定を操作できる権限）を手に入れます。本物のroot権限ではありませんが、tcの設定を触るには十分です。ここが攻撃の入り口になるため、「一般ユーザーが名前空間を自由に作れる状態かどうか」が、後述する緩和策の重要な分岐点になります。

2. act_peditのtyped keyで共有ページキャッシュを書き換える

次に攻撃者は、tcのact_peditアクションを、typed keyを使う形で設定します。前の章で触れたとおり、ここで書き込み範囲の計算漏れが発動します。攻撃者はファイルの内容をそのままネットワーク処理へ渡す経路（ゼロコピーと呼ばれる効率化の仕組み）を組み合わせ、本来は複製されて守られるはずだったページキャッシュ上のデータを、共有されたまま書き換えます。守りの観点では、「act_peditが読み込まれ、到達可能な状態になっていること」が成立条件である点を覚えておいてください。act_peditを使わせなければ、この段階は成立しません。

3. setuidバイナリのキャッシュ像を汚染してrootシェルへ

最終段階で狙われるのが、root権限で実行される代表的なsetuidプログラム（実行時に所有者の権限へ昇格する仕組みを持つコマンド）、たとえば/bin/suのメモリ上のキャッシュ像です。攻撃者はそのキャッシュされた実行イメージに小さな細工を施し、本来の処理の代わりに自分の用意した命令を埋め込みます。その後、汚染されたsuを通常どおり実行すると、埋め込まれた命令がroot権限で動き、攻撃者の手にrootシェルが渡ります。実証コード（PoC）はすでに公開されており、報告ではCVE採番から数日のうちに出回ったとされています。「まだ攻撃は来ていないはず」という前提は、この時点で成り立たなくなっていると考えるのが安全です。

重要なのは、この一連の流れが「パスワードの総当たり」や「正規ログインの失敗」といった、分かりやすい兆候をほとんど残さない点です。攻撃者は正規ユーザーとしてログインした後、静かにカーネルの内部処理を突きます。だからこそ、ログイン監視だけに頼らず、後述する別の角度からの検知が必要になります。

自分のサーバーが該当するかの確認と検知ポイント

まず確認すべきは、自分の環境がこの脆弱性の成立条件をどれだけ満たしているかです。すべての条件が揃って初めて悪用が現実になるため、逆に言えば、どれか一つを崩すだけでリスクは大きく下がります。次の項目を、SIEM（各種ログを集約して相関分析する仕組み）の検知ルールや手動点検のチェックリストとして使ってください。

・カーネルバージョンの確認: `uname -r`で稼働中のカーネルを確認し、Red Hatの該当バージョン情報と照らし合わせる
・act_peditの読み込み状況: `lsmod | grep act_pedit`で、当該モジュールが現在読み込まれているかを確認する
・ユーザー名前空間の許可状況: `sysctl user.max_user_namespaces`の値を確認し、一般ユーザーが名前空間を作成できる状態かを把握する
・不審なtc設定の有無: 通常運用で使っていないはずのpedit関連のtcルールが設定されていないかを確認する
・setuidプログラムの異常な実行: /bin/suなどのsetuidコマンドが、通常と違う文脈やタイミングで実行されていないかをログで追う

検知の観点で押さえておきたいのは、この攻撃が「権限昇格の瞬間」に分かりやすいログを残しにくいことです。そこで、攻撃が成立する前段に注目します。たとえば、一般ユーザーがユーザー名前空間を作成し、その内側でネットワーク設定（tc）を操作する、という組み合わせは、通常の業務ではあまり発生しません。auditd（Linuxの監査ログ機構）でtc関連のシステムコールやモジュールの読み込みを記録しておくと、攻撃の準備段階を捉えやすくなります。

もし上記のうち「act_peditの予期しない読み込み」や「業務外のpedit付きtcルール」が見つかった場合は、すでに悪用の準備、あるいは悪用そのものが進んでいる可能性を疑ってください。その際は、影響範囲の特定と封じ込めへ進み、判断に迷う場合は保守委託先やインシデント対応の専門事業者へ相談するのが現実的です。

いますぐ実施すべき緩和策と恒久対応

対応の軸はシンプルです。最優先は修正カーネルの適用で、それが難しい場合は攻撃の成立条件を崩す緩和策で時間を稼ぎます。専任担当がいなくても着手できる順に整理します。

1. 修正カーネルの適用（恒久対応・最優先）

根本対応は、ベンダーが提供する修正済みカーネルへの更新と再起動です。Red HatはRHEL 8・9・10のそれぞれに対して修正カーネル（errata）を提供しており、AlmaLinux 8やDebian 13でも対応が進んでいます。自分の環境に該当する具体的な更新（RHSA番号）は、サブスクリプションの状態によって異なるため、Red Hatの公式アドバイザリRHSB-2026-008と、各システムの更新管理から最新の該当情報を確認してください。更新後は再起動が必要です。再起動を保留したままだと、ディスク上のカーネルは新しくても、実行されているのは古いカーネルのままという食い違いが起きます。更新したつもりで守れていない、という落とし穴を避けるため、再起動後に`uname -r`で実際に新しいカーネルで動いていることを必ず確認してください。

2. すぐに更新できない場合のact_pedit無効化

検証や業務都合でカーネル更新を即座にできない場合は、攻撃の足場となるact_peditモジュールを読み込ませない緩和策があります。次の設定で、起動時の自動読み込みを抑止できます。

# act_pedit モジュールの読み込みを無効化する設定を追加
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf

# 設定後、現在読み込まれていないことを確認する
lsmod | grep act_pedit

ただし、この緩和策には注意点があります。tcのpeditを使ってパケットヘッダの書き換えやトラフィック整形を行っている環境では、無効化すると正規の機能まで止まってしまいます。自分の環境でpeditを業務利用していないかを確認したうえで適用してください。利用している場合は、無効化ではなく修正カーネルの適用を優先します。

3. 非特権ユーザー名前空間の制限

攻撃の入り口である、一般ユーザーによるユーザー名前空間の作成そのものを制限する方法もあります。EL系（RHELやその互換ディストリビューション）では、次の設定で一般ユーザーの名前空間作成を抑止できます。

# 一般ユーザーによるユーザー名前空間の作成を抑止（即時反映）
sudo sysctl -w user.max_user_namespaces=0

# 再起動後も維持されるよう設定ファイルに保存
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf

この設定は、コンテナ技術など一部のソフトウェアがユーザー名前空間を必要とする場合に影響することがあります。コンテナを動かしている環境では、業務への影響を確認したうえで適用してください。act_peditの無効化と名前空間の制限は、どちらか一方でも攻撃の成立条件を崩せますが、両方を組み合わせると守りはより堅くなります。

4. 緩和策が効いていることの確認

緩和策は、適用したことより「適用が効いていること」を確かめるところまでをワンセットにしてください。設定したつもりが反映されていなかった、というのはよくある落とし穴です。act_peditを無効化したなら`lsmod`で読み込まれていないこと、名前空間を制限したなら`sysctl user.max_user_namespaces`が0を返すことを、それぞれ実際に確認します。設定変更は、確認まで終えて初めて完了です。

中小企業でも今日からできること

専任のセキュリティ担当がいなくても、優先度の高い順に着手できます。難しく考えず、次のチェックリストを上から進めてください。

・該当確認: RHEL 8・9・10、またはその互換ディストリビューションを使っているサーバーを洗い出し、`uname -r`でカーネルを確認する
・更新計画: 該当するなら、Red HatのRHSB-2026-008を起点に修正カーネルの適用を最優先で計画する
・暫定の緩和: すぐ更新できないサーバーには、act_peditの無効化、または非特権ユーザー名前空間の制限を適用する
・痕跡の確認: act_peditの予期しない読み込みや、業務外のpedit付きtcルールがないかをログで点検する
・相談先の確保: 自前で判断が難しいときに相談できる保守委託先や専門事業者の連絡先を、対応を始める前に確認しておく

ローカル権限昇格の脆弱性は、つい「外から入られないなら後回しでよい」と考えがちです。けれども現実の攻撃は、外の小さな穴と内の昇格を組み合わせて成立します。外向きの守りと合わせて内側の昇格経路を塞いでおくことが、被害を局所で止める一番の近道です。慌てて手順を飛ばすと確認漏れが出ます。該当確認・更新または緩和・痕跡確認の順で、淡々と進めるのが結果的にいちばん速い対応になります。

よくある疑問（FAQ）

Q1. ローカルの脆弱性なら、外部に公開していないサーバーは無関係ですか？

無関係とは言い切れません。CVE-2026-46331は確かに「すでにそのサーバーで一般権限を持っている」ことが前提ですが、その前提は、フィッシングやWebアプリの脆弱性、漏れた認証情報などで簡単に満たされてしまいます。外部公開の有無にかかわらず、該当バージョンであれば更新または緩和を実施するのが安全側の判断です。

Q2. act_peditを無効化すれば、カーネルを更新しなくても大丈夫ですか？

act_peditの無効化は攻撃の成立条件を崩す有効な緩和策ですが、あくまで時間を稼ぐための暫定策です。同じカーネルには今後ほかの問題が見つかる可能性もあります。最終的には修正カーネルの適用が根本対応になりますので、無効化で急場をしのいだうえで、計画的に更新へ進めてください。

Q3. pedit COWという通称と、CVE番号はどう対応していますか？

「pedit COW」は、tcのact_pedit（pedit）における部分的なCOWの不具合という性質から付けられた通称で、正式な識別子はCVE-2026-46331です。記事や報道で通称が使われていても、対応すべき対象は同じものです。一次情報を確認する際は、NVDやRed HatのアドバイザリでCVE番号を基準に照合してください。

Q4. CVSSスコアが見当たりません。深刻度はどう判断すればよいですか？

本記事の執筆時点では、CVSSの確定値がまだ示されていません。その場合は、ベンダーの深刻度評価を判断の基準にします。Red Hatはこの脆弱性を「Important（重要）」と評価しており、これは対応を急ぐべき水準です。さらに実証コードが公開されている点を踏まえると、スコアの数値を待つより先に対応を進めるのが現実的です。

Q5. 修正カーネルを入れたのに、まだ古いカーネルと表示されます。なぜですか？

カーネルの更新は、再起動して初めて新しいカーネルで動き始めます。更新パッケージを適用してもディスク上に新しいカーネルが置かれるだけで、メモリ上では古いカーネルが実行され続けます。再起動後に`uname -r`を確認し、新しいバージョンになっていれば反映完了です。再起動を保留している間は、緩和策を併用しておくと安全です。

Q6. RHEL以外のディストリビューションは影響を受けますか？

影響はRHELに限りません。AlmaLinuxやDebianなど、同じLinuxカーネルの該当バージョンを使うディストリビューションも対象になり得ます。報告では、AlmaLinux 8やDebian 13で修正が提供される一方、一部のバージョンではまだ修正前という状況も示されています。自分が使っているディストリビューションの公式情報で、該当状況と修正提供の有無を確認してください。

Q7. 緩和策を入れたあと、誤って正規の通信が止まっていないか心配です。

その懸念はもっともです。act_peditを無効化すると、tcのpeditを使ったヘッダ書き換えや整形が止まります。これらを業務で使っているかどうかを事前に確認するのが大切です。使っていないなら無効化の影響はほぼありませんが、使っている場合は無効化ではなく修正カーネルの適用を優先してください。名前空間の制限についても、コンテナ環境への影響を確認したうえで適用すると安全です。

本記事のまとめ

CVE-2026-46331「pedit COW」は、Linuxカーネルのトラフィック制御（tc）の部品act_peditにある書き込み範囲の確認漏れにより、一般権限のユーザーがrootへ昇格できるローカル権限昇格の脆弱性です。RHEL 8・9・10がそろって対象で、Red Hatは「Important」と評価し、実証コードもすでに公開されています。外から入られないからと油断できる種類のものではありません。

やるべきことの軸はシンプルです。該当するサーバーを洗い出して修正カーネルの適用を最優先で進め、すぐ更新できないならact_peditの無効化や非特権ユーザー名前空間の制限で攻撃の成立条件を崩し、act_peditの予期しない読み込みなどの痕跡がないかを点検する。攻撃者から見れば、ローカル権限昇格は侵入の総仕上げに使う便利な部品です。その部品を取り上げてしまえば、たとえ足場を取られても、最後のひと押しは封じられます。正しく知れば、過度に恐れる必要はありません。落ち着いて、確認・更新（または緩和）・点検の順で守りを固めていきましょう。