Linuxカーネルのリアルタイムミューテックス(rtmutex)優先度継承コードに、ローカルの非特権ユーザから高い成功率でroot権限まで昇格できるstack use-after-free脆弱性CVE-2026-43499(通称GhostLock)が発見され、2026年7月7日にNebula Securityが技術詳細を公開しました。修正はLinux 7.1で入り、修正コミット`3bfdc63936dd`を含む安定版が既に配布されていますが、Ubuntuの公式CVEページでは記事執筆時点で24.04 LTS(noble)が「Vulnerable, work in progress」、22.04 LTS(jammy)と20.04 LTS(focal)が「Vulnerable」と表示されており、LTS系でも対応状況に差があります。バグは2011年のrtmutex reworkコミット`8161239a8bcc`で持ち込まれ、15年以上潜在してきました。
GhostLockの実務的な深刻度は3点に集約されます。第一に、必要な条件が「`CONFIG_FUTEX_PI=y`が有効」というほぼ全ディストロで既定で満たされる項目だけで、ユーザ権限も特殊設定もuser namespaceも要らない点。第二に、Nebula SecurityのVEGA(AI-native fuzzer)チームが実装した公開エクスプロイトが97％の安定性で動作し、コンテナ脱出まで達成している点。第三に、パッチ適用以外に完全な回避策が存在せず、`RANDOMIZE_KSTACK_OFFSET`や`STATIC_USERMODE_HELPER`といったビルドオプションは緩和にしかならない点です。同脆弱性は、Nebula Securityが「IonStack」と呼ぶ二段チェイン攻撃の後半にも位置付けられており、前半のFirefoxサンドボックス脱出(CVE-2026-10702)と組み合わせるとブラウザ訪問だけでrootまで到達する完全なエクスプロイトチェインが成立します。
GhostLock脆弱性の全体像
本脆弱性はLinuxカーネル`kernel/locking/rtmutex.c`の`remove_waiter()`関数に存在するstack use-after-free型メモリ安全性欠陥で、公表時点で実世界での悪用は報告されていません。Google kernelCTFへの提出として使用され、Nebula Securityは$92,337の報酬を獲得しました。実証コードは同社のオープンソースプロジェクトCyberMeowfiaで公開されています。
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-43499 |
| 通称 | GhostLock |
| 公表日 | 2026年7月7日 |
| 影響コミット範囲 | `8161239a8bcc`(2011年、Linux 2.6.39-rc1のrtmutex rework)〜 `3bfdc63936dd`(2026年4月) |
| 潜在期間 | 約15年 |
| 修正版 | Linux 7.1(初版修正(fix v1)は2026年5月4日にバックポート開始) |
| 関連する副次CVE | CVE-2026-53166(初回パッチが導入したNULLポインタ参照、続報で修正) |
| 攻撃前提条件 | `CONFIG_FUTEX_PI=y`が有効(ほぼ全ディストロで既定有効)、特別な権限・user namespace不要 |
| 攻撃効果 | 非特権ローカルユーザからのroot権限取得およびコンテナ環境からの脱出 |
| 公開エクスプロイトの成功率 | 97％(Nebula Securityによる測定) |
| kernelCTF報酬 | $92,337 |
| CVSSスコア | CNA(kernel.org)評価ではCVSS v3.1 Base Score 7.8(High、CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)。NVDのNIST評価は記事執筆時点で未提供。Ubuntu priorityはMedium。 |
| 完全な回避策 | なし(mitigationのみ、詳細は本文参照) |
rtmutexとRequeue-PIの位置付け
Linuxカーネルの`rt_mutex`(リアルタイムミューテックス)は、優先度反転(priority inversion)を防ぐために優先度継承(priority inheritance、以降PI)機構を組み込んだ排他制御プリミティブです。低優先度タスクがロックを保持しているあいだ、そのロックを待つ高優先度タスクの優先度をロック保持者に「継承」させることで、中優先度タスクによる先行実行がリアルタイム処理を止めないようにする役割を果たします。ユーザ空間からはPI対応のfutex(FUTEX_LOCK_PI等)を通じてこの機構を利用します。
Requeue-PIはさらに複雑で、あるfutexで待機しているタスクを別のPI futexへ「再キュー」する操作を提供します。プロデューサ・コンシューマ型の待機切り替えを、条件変数などの高水準プリミティブが内部で使う機能で、PI連鎖の一貫性を保ったまま待機対象を差し替えるための機構です。GhostLockが問題となるのは、この再キューが失敗したときのロールバック経路にあります。
脆弱性の技術的な原理
`remove_waiter()`関数は、rtmutexの待機列からwaiterを取り除き、そのwaiterに関連するPI連鎖の状態を後片付けする内部ヘルパです。関数の内部で`current->pi_blocked_on`をNULLにクリアする処理が入っており、これは「タスクが自分自身のためにブロックしていて、自分で後片付けする」という単一シナリオでは正しく機能します。この設計上の暗黙前提が、Requeue-PI経由のプロキシパスで崩れることがGhostLockの根本原因です。
Requeue-PIでは`rt_mutex_start_proxy_lock()`が別のスリープ中タスクの代わりに`rt_mutex_waiter`をエンキューします。ここで、rtmutexのチェイン走査中にPI依存サイクルが検出されると`-EDEADLK`が返り、`remove_waiter()`が呼ばれてロールバックが行われます。この時点で`current`は再キューを要求したスレッドであり、実際にスリープしているwaiterタスクとは別物です。しかし関数は依然として`current->pi_blocked_on`をクリアするため、実際のwaiterタスク側の`pi_blocked_on`は自分のカーネルスタック上の`rt_mutex_waiter`オブジェクトを指したまま残ります。
ここまでで脆弱性の下地が完成します。waiterタスクはユーザ空間に戻り、`FUTEX_WAIT_REQUEUE_PI`のスタックフレームが解放されますが、`pi_blocked_on`はそのフレーム内の`rt_mutex_waiter`を指し続けます。以降にwaiterタスクを対象とするPI連鎖走査(たとえば`sched_setattr()`経由)が発生すると、このdangling pointerを辿って解放済みのスタックメモリを`rt_mutex_waiter`として参照するuse-after-freeが発火します。走査のあいだ、解放済みスタックの上に攻撃者が制御した内容を撒き直すことができれば、偽の`rt_mutex_waiter`として振る舞わせられます。
Nebula Securityは、この初期プリミティブから最終的なroot権限取得までのエクスプロイトチェインを、`PR_SET_MM_MAP`によるスタックフレーム再取得、`prefetch`サイドチャネルによるKASLR回避、CPU entry area(CEA)を経由した制御フロー乗っ取り、そして`core_pattern`の`ctl_table::mode`ビットを書き換える「DirtyMode」と呼ぶ最終段で、5秒程度でrootを取れる形にまとめています。細部は同社の公開技術レポートに委ねますが、チェインの各段が相互に補強し合う設計になっており、97％という高い成功率もこの緻密な組み立ての帰結です。
15年間気づかれなかった理由
GhostLockが15年間発見されなかった構造的な理由は、rtmutexのrework以降ほぼ手が入っていない領域だったことに尽きます。導入は2011年の`8161239a8bcc`(「rtmutex: Simplify PI algorithm and make highest prio task get lock」)で、rt_mutex_waiterのライフサイクルが再設計されたタイミングでした。以降、futex PI関連のバグは複数見つかっていますが、`remove_waiter()`のこの設計上の暗黙前提そのものは検査の網から漏れ続けました。
設計上の暗黙前提が15年間もそのまま残った理由は、Requeue-PIのロールバック経路が実運用では非常に稀な条件でしか発火せず、通常のワークロードでは問題として顕在化しないことにあります。3つのPI futexと3つのスレッドで構成されるデッドロックサイクルを意図的に組み立てないと`-EDEADLK`にすら到達しないため、自然な負荷では踏まれず、コードレビューでも「単スレッドのセルフブロッキング」という原設計の文脈で読まれ続けました。lockdepでも捕捉できず、これは同サニタイザが「`pi_lock`が保持されているか」は検査するものの、「それが正しいタスクの`pi_lock`か」までは追跡しないためです。
この構造は、Nebula SecurityがVEGAという自動ファジングツールで発見したこと、そして同じ時期に他の同種脆弱性が相次いで公表されていることと無関係ではありません。同社は本レポート内で、futex priority inheritanceが2011年から存在する「古い、重く使われているカーネル機構で、長期間十分に再監査されてこなかった領域」だと明示しており、自動化ツールがこうしたレガシー領域を系統的に洗い直す段階に業界が入ったと整理しています。
2026年前半のLinuxカーネルLPE脆弱性群と自動化ツールの潮流
GhostLockは2026年前半に相次いだLinuxカーネル特権昇格脆弱性群の一つとして位置付けられます。数日前に公表されたBad Epoll(CVE-2026-46242)は同じくkernelCTF経由で実証された非特権→root脆弱性で、このクラスのバグとしては珍しくAndroidでも動作することが確認されました。Bad Epollが位置するコード領域は、AnthropicのMythosモデルが関連脆弱性の発見でクレジットされている場所でもあり、AIモデルによるカーネルコード監査の実例として注目されています。前月のJanuscape(CVE-2026-53359)はKVM/x86のShadow MMUに存在する16年物のuse-after-freeで、ゲストからホストへの脱出を可能にしていました。
もう一つ重要な参照点はCopy Fail(CVE-2026-31431)で、こちらは既にCISAの既知悪用脆弱性(KEV)カタログに掲載されており、実世界での攻撃観測が確認されています。Copy Fail・Bad Epoll・Januscape・GhostLockの4件はいずれも、長期間潜在した古典的カーネルサブシステムを対象にしている点、そしていずれも自動化ツールもしくはAI支援型の監査プロセスで発見されている点が共通しています。個別バグとしてではなく、Linuxカーネル基盤に対する構造的な監査再開の一連の産物として捉えるのが実態に即します。
IonStack: Firefoxからrootへの完全チェイン
Nebula SecurityはGhostLockを、単独脆弱性としてだけでなく「IonStack」と呼ぶ二段チェインの後半として位置付けています。前半はCVE-2026-10702というFirefoxの脆弱性で、悪意あるWebページを開くとブラウザプロセス内でコード実行が可能になり、Firefoxのサンドボックスから脱出できます。ただしこの段階ではまだ非特権ローカルユーザとしての権限しかありません。ここでGhostLockが後半を担い、サンドボックス脱出後の非特権プロセスからroot権限を取得します。
この二段構成は、現代のLinuxデスクトップ・サーバ環境でブラウザから始まる攻撃者視点の完全なエクスプロイトチェインがどのように構成されるかを示す実例です。単独のブラウザ脆弱性はサンドボックスで隔離され、単独のカーネルLPEは初期実行手段がなければ発火できませんが、両者を組み合わせるとWebページ訪問だけでrootまで到達します。GhostLockのようなカーネル層のLPE脆弱性が、ブラウザ脆弱性とは独立に、しかし相互補完的に価値を持つ理由がここにあります。
修正確認と実務対応
GhostLockへの対応は、Linux 7.1がリリース済みの環境か、修正コミット`3bfdc63936dd`とCVE-2026-53166対応の続報修正コミット`74e144274af3`の両方がバックポートされたディストロ提供カーネルへの更新が基本です。Nebula Securityおよび複数の分析ソースが強調する運用上のポイントを整理すると、次の通りです。
- ディストロ側の対応状況を明示的に確認:Ubuntuでは公式CVEページ確認時点で24.04 LTS(noble)が「Vulnerable, work in progress」、22.04 LTS(jammy)と20.04 LTS(focal)が「Vulnerable」、25.10(questing)も「Vulnerable」と表示されており、LTS系でも対応進捗に差があります。26.04 LTS(resolute)は既に「Fixed 7.0.0-27.27」として修正済みで、AWS/GCP/Azureなどクラウド固有のカーネル系統もそれぞれ独立に対応状況を確認する必要があります。カーネルバージョン番号だけでは判断できないため、ディストロ提供のセキュリティアドバイザリで具体的なパッケージバージョンを確認します。
- マルチテナント・共有環境の優先:攻撃には非特権ローカル実行が必要なため、クラウドサーバ、コンテナホスト、CIランナー、社内共有ホストなど、非信頼ユーザや攻撃者由来のプロセスが動く環境を最優先で対応します。GhostLockはコンテナからの脱出も可能なため、コンテナ隔離を防御境界として扱っている構成では特にリスクが高くなります。
- 完全な回避策は存在しない:攻撃を発火させるための操作(futex系のシステムコール、`prctl(PR_SET_MM_MAP)`など)はいずれもローカルプロセスの通常操作の範疇で、これらを禁止する運用は現実的ではありません。パッチ適用が唯一の根本対処です。
- ビルドオプションによる緩和策の限界:`RANDOMIZE_KSTACK_OFFSET`は解放済みスタックフレームの再取得を1/32(5ビット)の当たり運に変え、`STATIC_USERMODE_HELPER`はDirtyModeで使われる`core_pattern`経由のroot取得経路をブロックします。ただし前者は成功率を下げるだけで、後者も一般化された同種手法には別の`ctl_table::mode`権限チェック付きの設定項目が標的として使えるため、いずれも完全な防御ではありません。
- IonStackを踏まえたブラウザ側の同時対応:GhostLockはFirefoxのCVE-2026-10702と組み合わせるとフルチェインになります。エンドユーザ端末ではブラウザ側の最新版適用も並行して確認し、二段のうちどちらか一段の対処がまだの端末を素通りにしないよう管理します。
- 組み込み・IoT系の見落としに注意:Nebula Security本人のツイートに「IoTからモバイル、デスクトップまで、Linuxを動かすすべてが影響を受ける」との明示があり、パッチ提供が遅れがちな組み込み系Linuxデバイスは長期にわたって残存リスクを抱えます。ネットワーク越しの侵入経路がある機器では、GhostLockが「侵入後の権限昇格ステップ」として組み込まれる可能性を想定した設計見直しが必要です。
Nebula Securityが実証コードをGitHubで公開している以上、悪用に転用されるリスクは高まっています。実悪用が確認されればCISA KEVに追加される可能性もあるため、既にCISA KEV掲載済みのCopy Failと同様に、公開エクスプロイトが出た後の悪用移行を前提にパッチ適用のリードタイムを短くしておく必要があります。特にコンテナホストと共有CI基盤の更新プロセスの再点検が、実務上の急務です。
一次情報・公式情報
- IonStack part II: GhostLock, a stack-UAF that has existed in ALL Linux distributions for 15 years(Nebula Security、2026年7月7日、発見者の公式技術レポート)
- CyberMeowfia / IonStack / CVE-2026-43499(Nebula SecurityによるオープンソースPoCおよび技術資料)
- 修正コミット`3bfdc63936dd`(rtmutex: Use waiter::task instead of current in remove_waiter())
- 導入コミット`8161239a8bcc`(2011年、rtmutex rework)
- Google kernelCTFプログラム公式ルール
参考情報
- 15-Year-Old GhostLock Flaw Enables Root and Container Escape on Most Linux Distros(The Hacker News、2026年7月8日)
- New Januscape Linux flaw allows VM escape on Intel, AMD devices(BleepingComputer、Januscape続報、2026年7月7日)
- Public Exploit for GhostLock (CVE-2026-43499) Enables Linux Privilege Escalation and Container Escape(SecurityOnline)
- Nebula Security公式Twitter発表(GhostLockはIoT/モバイル/デスクトップすべてに影響)
- Prefetch Side-Channel Attacks(Gruss et al.、GhostLockエクスプロイトが利用するKASLRリーク技術の原典)
slug: ghostlock-linux-rtmutex-cve-2026-43499
コメント