Linuxカーネルに15年前から潜む脆弱性「GhostLock」の公開実証コードが登場、わずか5秒でルート権限奪取が可能に

2026年7月9日 18:55

2011年からLinuxカーネルに存在していた脆弱性「GhostLock」（CVE-2026-43499）に対する実証コード（PoC）が公開された。ログイン済みのユーザーであれば、特別な設定や管理者権限、ネットワーク接続を必要とせず、約5秒で対象マシンの完全なルート権限を奪取できるとされる。この脆弱性はDockerやKubernetesなどのコンテナ環境を回避してホスト側に侵入することも可能であるため、クラウドや共有インフラを運用する組織にとってパッチ適用が最優先課題となっている。

■15年間見過ごされてきた優先度継承コードの欠陥

セキュリティ企業Nebula SecurityのVEGAチームは2026年7月7日、GhostLockの技術詳細とオープンソースの実証コードを公開した。Googleのバグ報奨金プログラム「kernelCTF」は、この報告に対して9万2,337ドル（約1,505万円、1ドル＝163円換算）を授与した。この高額な報奨金は、バグの深刻さと攻撃手法の完成度の高さを反映している。

この脆弱性は、Ubuntu、Debian、Red Hat Enterprise Linux、Fedora、Archなど、2011年5月以降にビルドされたカーネルを採用するほぼすべての主要なLinuxディストリビューションに、15年もの間検出されずに存在し続けていた。GhostLockはLinuxカーネルバージョン2.6.39で混入し、7.1-rc1まで到達可能な状態だった。本家（アップストリーム）ではすでに修正パッチが存在するが、各ディストリビューションのパッケージ配布は現在も進行中であり、2026年7月8日時点でUbuntuの3つの長期サポート（LTS）リリース（24.04、22.04、20.04）は依然として脆弱であるか、対応中とされている。

■脆弱性の技術的背景：スタックのUse-After-Free

GhostLockは、Linuxカーネルのリアルタイムミューテックス（rt_mutex）サブシステムにおける「優先度継承（priority inheritance）」と呼ばれるメカニズム内に存在する。これは、低優先度のタスクがロックを保持しているために高優先度のタスクがブロックされる「優先度逆転」を防ぐため、一時的に低優先度タスクの優先度を引き上げる仕組みである。

問題は、クリーンアップ関数「remove_waiter()」が、本来の用途とは異なる「Requeue-PIプロキシパス」で再利用されたことに起因する。このパスでは、システムコールを実行しているスレッドと、休止中のウェイタータスクが異なるため、関数が誤って別のタスクの「pi_blocked_on」をクリアしてしまう。その結果、休止中のウェイターは、すでに解放されたカーネルスタック上のオブジェクトを指したままのポインタ（ダングリングポインタ）を持ってユーザー空間に戻ることになる。

このスタック上でのUse-After-Free（解放後メモリ利用）の脆弱性を利用し、Nebulaのチームは複数のステップを組み合わせて完全なルート権限奪取を実現した。解放されたスタックフレームを偽装構造体で再利用し、カーネルにそれを参照させて関数ポインタを書き換え、最終的にユーザー空間のみで権限昇格を完了させる。この実証コードは、一般的な構成において97%という極めて高い成功率で、約5秒でルート権限に到達するという。

■CVSSスコア「7.8」が覆い隠す真のリスク

GhostLockのCVSS（共通脆弱性評価システム）スコアは10点満点中「7.8」であり、評価は「緊急（Critical）」ではなく「重要（High）」にとどまっている。これは、攻撃者がすでにマシンへのローカルアクセス権を持っている必要があるという前提に基づいているためだ。しかし、この評価だけでパッチ適用の優先度を低く見積もるべきではない。

Nebulaによれば、GhostLockは「IonStack」と呼ばれる2段階攻撃チェーンの後半部分に相当する。前半部分は、FirefoxのJavaScriptコンパイラにおける脆弱性「CVE-2026-10702」（2026年6月2日にFirefox 151.0.3で修正済み）であり、これらを組み合わせることで、ローカルアクセスの前提条件は完全に解消される。Android版Firefoxで悪意あるリンクを1回タップするだけで、デバイスの完全な制御を奪取できることが実証されており、実質的なリスクはCVSSスコアの数値を大きく上回る。

■コンテナ回避によるクラウド環境への脅威

GhostLockがもたらす最大の懸念は、コンテナ回避（コンテナエスケープ）が可能である点だ。DockerやKubernetesなどのコンテナ環境は、ホストカーネルを共有しているため、ホストカーネルの脆弱性が突かれるとセキュリティ境界が完全に崩壊する。

Nebulaのテストにおいて、GhostLockは特別なコンテナ権限や昇格された特権を必要とせず、コンテナ内部からの実行に成功した。Webアプリケーションの脆弱性やサプライチェーン攻撃などを通じてコンテナ内に侵入した攻撃者は、GhostLockを利用してホスト側に脱出し、基礎となるノードのルート権限を奪取できる。これにより、同じKubernetesノードを共有する他のワークロードや、マルチテナント環境における他顧客のデータにまで影響が及ぶ恐れがある。

■インフラ担当者が取るべき対策

GhostLockの修正パッチ適用にあたっては、単に最初のアップデートを適用するだけでは不十分な場合がある。最初に提供されたアップストリームの修正（コミット3bfdc63936dd）では、特定の条件下でヌルポインタ参照が発生する二次的なバグ（CVE-2026-53166）が残されており、完全な修正は2026年7月初旬にかけて段階的に行われた。そのため、初期のディストリビューションビルドには不完全な修正しか含まれていない可能性がある。

実務的な対策として、セキュリティおよびインフラチームは以下の対応を推奨される：

1. 各ディストリビューションのセキュリティ情報を確認し、二次バグまで修正された最新のカーネルパッケージが適用されているか確認すること。2026年7月8日時点で、UbuntuのLTSバージョン（24.04、22.04、20.04）などは依然として対応中または脆弱な状態とされている。

2. カーネルのビルドオプションである「RANDOMIZE_KSTACK_OFFSET」や「STATIC_USERMODE_HELPER」は攻撃を困難にするものの、完全に防ぐことはできないため、パッチ適用の代替とはみなさないこと。

3. この脆弱性を引き起こすシステムコール（FUTEX_WAIT_REQUEUE_PIなど）は、データベースやJVMなどの一般的なマルチスレッドアプリケーションで日常的に使用されているため、システムコール自体をブロックするような運用の回避策は現実的ではない。

4. クラウドサーバー、コンテナホスト、CI/CDランナーなど、攻撃者が低権限の足がかりを得やすい共有・マルチテナント環境へのパッチ適用を最優先とすること。

■AIツールによる脆弱性発見の光と影

GhostLockは、AIを活用した脆弱性発見システムによって短期間に発見された2つ目の重要なLinuxカーネルの脆弱性であり、先に公開された「Bad Epoll」（CVE-2026-46242）と共通のパターンを示している。NebulaのVEGAプラットフォームは、2006年のLinux 2.6.18から存在し、これまで厳密な自動解析が行われてこなかったrtmutexの優先度継承コードからGhostLockを特定した。

一方で、AIによるコード監査にはまだ限界もある。Bad Epollの発見においては、Anthropicの「Mythos」モデルが2つのレースコンディション（競合状態）のうち1つを発見したものの、もう1つを見落とし、最終的に人間の研究者がそれを補完した。これらの事例は、AIが長年見過ごされてきた古いコードのバグを発見する能力を持つ一方で、すべてのコードパスを網羅的に監査できる段階にはまだ達していないことを示している。

■注目ポイントQ&A

●GhostLockはサーバーだけに影響しますか？ デスクトップユーザーもパッチが必要ですか？

CONFIG_FUTEX_PIが有効な未パッチのLinuxカーネルを実行しているすべてのシステム（デスクトップ、サーバー、クラウド仮想マシン、コンテナホスト）が影響を受けます。デスクトップ環境では攻撃者がローカルアクセスを得る必要がありますが、共有サーバーやマルチテナント環境では、一般ユーザー権限で実行されている侵害されたプロセスから悪用される危険性があります。デスクトップユーザーもパッチを適用すべきですが、共有インフラへの対応が最優先となります。

●Firefoxのバグと組み合わせることでリモート攻撃が可能になるのに、なぜCVSSスコアが7.8なのですか？

CVSSは個々の脆弱性を単体で評価するため、ローカルアクセスを必要とするGhostLock単体では「7.8（重要）」と評価されます。しかし、FirefoxのJIT脆弱性（CVE-2026-10702）と組み合わせた「IonStack」攻撃チェーンでは、悪意あるWebページを閲覧するだけでリモートからデバイスを完全制御されるリスクが生じます。実質的なリスクはCVSSスコアよりもはるかに高いと捉えるべきです。

●システムがすでにGhostLockによって侵害されているかどうかを判断する方法はありますか？

2026年7月8日時点で、野生（実環境）での悪用事例は確認されていません。しかし、この脆弱性は標準的なシステムコールを使用するため、通常の監査ログから悪用を検出することは困難です。FalcoやeBPFベースのカーネル監視ツールを導入している組織は、予期しない権限昇格パターンや不審なFUTEX_CMP_REQUEUE_PI呼び出しシーケンスを監視することで検知できる可能性があります。最も確実な対策は、悪用される前にパッチを適用することです。

●Use-After-Free（解放後メモリ利用）脆弱性とは何ですか？ なぜカーネルコードにおいて危険なのですか？

メモリが解放されてアロケータに戻された後も、コードがそのメモリ領域を参照し続けることで発生する脆弱性です。ユーザー空間では単なるクラッシュで済むことが多いですが、カーネル空間では解放されたメモリが別のデータ構造に再割り当てされるため、機密データの漏洩や、任意のカーネルオブジェクトの改ざんにつながる恐れがあります。GhostLockのようなスタック上のUse-After-Freeは比較的珍しく、攻撃者が後続のシステムコールを通じて解放されたスタックフレームの内容を精密に制御できるため、非常に高い信頼性で悪用が可能になります。

元記事: Public Exploit Turns 15-Year Linux Kernel Flaw Into 5-Second Root Attack

関連記事

最新記事