Linuxカーネルの脆弱性「Bad Epoll」が公開、AI監査をすり抜け99%の確率でroot権限奪取が可能に

2026年7月8日 09:29

2026年7月3日、Linuxカーネルに存在する深刻な競合状態の脆弱性「Bad Epoll（CVE-2026-46242）」が公開された。この脆弱性を悪用すると、カーネルv6.4以降を実行しているデスクトップ、サーバー、Androidデバイスにおいて、権限のないローカルユーザーが99%という極めて高い成功率でroot権限を取得できるとされる。本脆弱性は、最先端AIモデルによる監査をもすり抜けており、AI支援型セキュリティ研究の現状と限界を示す事例としても注目を集めている。

■「Bad Epoll」の概要と回避策が存在しない理由

「epoll」は、プログラムがCPUリソースを無駄に消費することなく、数千ものファイル記述子、ソケット、パイプを同時に監視できるようにする、Linuxの効率的なI/Oイベント通知の基盤メカニズムである。現代のLinuxネットワークサービスやWebブラウザ、Androidアプリケーションのほぼすべてがこれに依存している。

管理者が必要に応じてアンロードできる脆弱なカーネルモジュールとは異なり、epollはオペレーティングシステム（OS）の動作に不可欠なため、無効化することができない。そのため、Bad Epollに対する一時的な回避策（ワークアラウンド）は存在せず、唯一の恒久的な対策はカーネルパッチの適用のみとなる。この「キルスイッチが存在しない」という特性が、Bad Epollを他の多くのLinux権限昇格バグよりも格段に危険なものにしている。

■ep_remove()における競合状態：バグの仕組み

Bad Epollは「Use-After-Free（解放後メモリ使用）」と呼ばれるメモリ脆弱性の一種である。これは、メモリが解放され、場合によっては再割り当てされた後も、コードがそのメモリへのアクセスを継続してしまうことで発生する。具体的な欠陥は、epollファイル記述子が閉じられる際にクリーンアップを行う関数「ep_remove()」内に存在する。

2つのepollファイル記述子が互いを監視するように設定され、ほぼ同時に閉じられたときに競合状態が発生する。ep_remove()はロック下でファイルの「f_ep」ポインタをクリアするが、同じクリティカルセクション内でそのファイルオブジェクトを使用し続け、「hlist_del_rcu()」や「spin_unlock()」を実行する。このとき、別のCPUで同時に実行されている「__fput()」の呼び出しが一時的なnull値を検知し、「eventpoll_release()」を介して高速処理ルートを通るため、適切なクリーンアップがスキップされ、ep_remove()が書き込みを行っている最中に基礎となる「struct eventpoll」が解放されてしまう。

Linuxカーネルの「struct file」型は「SLAB_TYPESAFE_BY_RCU」としてマークされているため、解放されたメモリ領域は「alloc_empty_file()」によって再利用される可能性がある。これにより、攻撃者は誤ったスラブキャッシュに対して「kmem_cache_free()」を誘発させ、再利用された「kmalloc-192」メモリへの書き込みを行い、最終的に任意のカーネル書き込み経路を開くことが可能になる。

■実証された99%の攻撃成功率

研究者のJaeyoung Chung氏が公開したエクスプロイトは、この脆弱性の悪用が単なる「運任せ」ではないことを証明している。同氏のエクスプロイトは、2組に配置された4つのepollオブジェクトを使用する。1組は競合状態を誘発させるため、もう1組は結果として生じるメモリ破損の標的とするためである。8バイトのUse-After-Free（UAF）書き込みは、クロスキャッシュ攻撃を介してファイルオブジェクト上の完全なUAFへと連鎖され、さらに「/proc/self/fdinfo」をまたぐ「struct file」参照をぶら下げることで、任意のカーネルメモリ読み取りへと繋げられる。

さらに、ROP（Return-Oriented Programming）チェーンを介して制御フローが乗っ取られる。タイマー割り込み技術によって競合の発生窓（タイミング）が広げられ、カーネルをクラッシュさせることなく再試行ループが実行される。その結果、LTS-6.12.67カーネルのkernelCTFターゲットにおいて99%、COS-121ターゲットにおいて98%という極めて高い信頼性でroot権限の奪取に成功したという。詳細な解説とコードは、Bad EpollのGitHubリポジトリで公開されている。

なお、カーネルメンテナーによる最初のパッチ適用試行では問題が完全には解決しなかった。Chung氏の最初の報告から、メインラインに正しい修正パッチが取り込まれるまでに66日を要した。これは、セキュリティ問題に対して通常迅速に動くカーネルプロジェクトとしては長い期間である。

■Androidデバイスも標的に

多くのLinux権限昇格バグはAndroidデバイスには影響しないが、epollにはそのような境界線が存在しない。Androidは、バインダー依存のカーネルモジュールのようにepollを排除することができないためである。GoogleのkernelCTFプログラムでこれまでに悪用された約130件の脆弱性のうち、Androidのroot化に現実的に利用可能なものは約10件のみであり、Bad Epollはその1つに該当する。

具体的な影響範囲として、カーネルv6.4以降を実行しているデバイスが脆弱である。このバグは2023年4月8日のコミットによって導入されたものであり、それ以前の古いv6.1カーネルツリーには存在しない。したがって、「Pixel 8」などのv6.1ベースのAndroidデバイスは影響を受けない。一方、「Pixel 10」などのカーネルv6.6以降を実行するデバイスは影響範囲に含まれる。Chung氏のチームは、Pixel 10上で基礎となるメモリ破損を誘発させる概念実証（PoC）を確認しており、2026年7月4日時点で完全なrootエクスプロイトチェーンを開発中であると報告している。

さらに緊急性を高める要因として、Bad EpollはGoogle Chromeのレンダラーサンドボックス内からトリガーできる。この環境はカーネルバグをブロックするために特別に強化されており、既知のほぼすべてのカーネルエクスプロイトを阻止するが、Bad Epollは例外となる。侵害されたブラウザのレンダラータブからBad Epollを連鎖させることで、脆弱なデバイスのroot権限を奪取される危険性がある。

■2026年のカーネル脆弱性ランドスケープにおける位置づけ

「Bad Epoll」という名称は意図的なものである。これは、Androidをroot化可能なカーネルバグの系譜である「Bad Binder」「Bad IO_uring」「Bad Spin」に続くものであり、今回はepollサブシステムに焦点を当てたものとなる。

2026年のLinuxカーネル脆弱性を取り巻く環境は、例年にないほど混雑している。4月には「algif_aead」モジュールにおける決定論的な権限昇格脆弱性「Copy Fail（CVE-2026-31431）」が登場し、米国土安全保障省サイバーセキュリティ・インフラセキュリティ庁（CISA）の「悪用が確認済みの脆弱性カタログ（KEV）」に登録された。さらに、2022年に悪名高かった「Dirty Pipe」と同様のページキャッシュ書き込みプリミティブを悪用する「DirtyFrag」チェーン（Fragnesia: CVE-2026-46300、DirtyClone: CVE-2026-43503、pedit COW）が続いた。また、AI主導のセキュリティ企業Bynarioが発見したFUSEファイルシステムドライバの脆弱性「CVE-2026-31694」の公開PoCも登場している。ただし、こちらはFUSEへのアクセスが必要なため、スマートフォンよりも主にサーバーやコンテナ環境がリスクにさらされる。

これらの決定論的なバグとBad Epollの決定的な違いは、前者が実行すれば必ず成功するのに対し、後者は競合状態（レースコンディション）を勝ち取る必要がある点である。かつて、公開前に何年にもわたって悪用され、読み取り専用のカーネルマッピングへの書き込みを可能にした「Dirty COW（CVE-2016-5195）」は、このクラスの典型例であった。Bad Epollはその2026年における後継であり、99%という攻撃成功率は、「競合状態のバグは信頼性が低い（成功しにくい）」という常識を覆すものとなっている。

■最先端AIは一方のバグを発見し、もう一方を見落とした

2023年4月8日にマージされた単一のコミット（58c9b016e128）により、カーネルのepollコードに2つの異なる競合状態が導入された。これらはどちらも悪用可能な権限昇格バグであった。Anthropicの「Project Glasswing」の下で展開された最先端AIモデル「Mythos」は、このコードをレビューし、1つ目の脆弱性「CVE-2026-43074」（2026年4月2日にメインラインで修正済み）を発見した。しかし、Mythosは2つ目の脆弱性である「Bad Epoll」を見落としていた。

Chung氏は、AIがこのバグを見落とした理由について、技術公開文書の中で「正確な理由は不明だが、2つの要因が発見を困難にしたと考えられる」と分析している。

1つ目の要因は、競合が発生するタイミング（実行窓）がわずか6命令分という極めて狭い範囲であることだ。このようなスレッドの交差を正確にイメージすることは、コードを凝視する人間の監査役にとっても困難であり、並行実行パスを抽象的に推論するAIモデルにとってはさらに難しかった可能性がある。

2つ目の要因は、認識論的な問題である。1つ目の「CVE-2026-43074」が修正された後、Bad Epollはカーネルの主要な動的メモリ誤り検出器である「KASAN」をトリガーしなくなった。KASANは解放されたアロケータ領域を汚染（ポイズニング）してその後のアクセスを検出するが、Bad Epollが使用するクロスキャッシュ再利用パスはこの検出窓を回避してしまう。そのため、動的テストを実行してもクラッシュやKASANのアラートは発生せず、同じコードパスに2つ目のバグが隠されている兆候は得られなかった。静的な推論だけでは確信が持てず、実行時の証拠に依存するAIモデルにとって、確認の手がかりが失われていたことになる。

この出来事は、AI支援型セキュリティ研究を否定するものではない。Mythosが難解なカーネルサブシステムで競合状態を発見したこと自体は本物の成果である。しかし、この事例が明確に示しているのは、「コードパス内で1つのバグが見つかったからといって、そのコードパス全体が安全であるとは限らない」ということだ。最先端AIモデルによる「レビュー済み」のスタンプを、そのまま安全宣言として扱うことはまだできない。

■AIは修正能力を超えるペースでバグを発見しているのか？

Bad EpollのニュースはAIの限界を示す話として捉えられがちだが、別の側面もある。2026年5月22日時点で、AnthropicのProject Glasswingは281のオープンソースプロジェクトにわたって1,596件の脆弱性を公開したが、そのうち修正されたのはわずか97件（約6%）にとどまっている。

この低い修正率はAnthropicの落ち度ではなく、オープンソースエコシステムの構造的な制約によるものである。AI支援による脆弱性研究のボトルネックは、すでに「発見」から「修正（パッチ適用）」へと移行している。Linus Torvalds氏は2026年5月17日の「Linux 7.1-rc4」リリース投稿において、AIが生成したバグ報告によってカーネルのプライベートセキュリティチャネルが「ほぼ管理不能」な状態になっており、複数のツールが同じ欠陥を報告することで、真に深刻度の高い報告が埋もれてしまっていると不満を漏らした。現在、既知の高深刻度または緊急のCVEを修正するまでの平均期間は74日となっており、CVEの総数は2025年に48,185件に達している。

Bad Epollの本質は、「AIがバグを見落とした」ことではなく、AIが発見したバグ（CVE-2026-43074）が修正された結果、隣接する別のバグの存在を示す実行時シグナルが消え去ってしまったという点にある。そして、より深刻な現実は「Glasswingが1,596件のバグを発見したにもかかわらず、97件しか修正されていない」という事実である。最先端AIモデルの目をかいくぐった今回の競合状態は、そのような状況下で「幸運にも人間が発見できたバグの1つ」に過ぎない。

■今すぐ取るべき対策

Linuxデスクトップおよびサーバーのユーザーは、利用しているディストリビューションのセキュリティ情報を確認し、コミット「a6dc643c6931」をバックポートしたカーネルアップデートを適用する必要がある。バックポートが適用されていないv6.4以降のカーネルを実行しているすべてのシステムが脆弱である。特に、マルチユーザーシステム、コンテナビルドホスト、および信頼できないコードがシェルにアクセスできる環境では、パッチ適用を最優先すべきである。

一時的な緩和策はあるものの、効果は限定的である。KASLR（カーネルアドレス空間配置のランダム化）やSLUBランダム化を有効にすると、攻撃の難易度は上がるが、根本的な解決にはならない。また、epoll自体を無効化する方法はないため、パッチの適用が唯一の解決策となる。

Androidユーザーに関して、「Pixel 8」などのカーネルv6.1を実行しているデバイスは影響を受けない。「Pixel 10」などのカーネルv6.6以降を実行しているデバイスのユーザーは、Googleからセキュリティアップデートが提供され次第、速やかに適用する必要がある。現時点でAndroidを標的とした完全なrootエクスプロイトは公開されていないが、Chung氏のチームがメモリ破損のPoCを確認しており、開発を進めているため、今後のAndroid向けセキュリティ情報に注意する必要がある。

セキュリティチームは、2026年7月4日時点でCVE-2026-46242がCISAのKEVリストに登録されておらず、野生での悪用も確認されていないことを把握しつつも、PoCが公開されていること、および99%という高い成功率から、Android向けのエクスプロイトチェーンが完成すれば標的型攻撃への悪用が容易であることを認識し、迅速なパッチ適用計画を進めるべきである。

■注目ポイントQ&A

●Bad Epollの影響を受けるカーネルバージョンと、確認方法を教えてください。

Bad Epollは2023年4月8日のコミットによって導入され、コミット「a6dc643c6931」のバックポートが適用されていないv6.4以降のカーネルに存在します。v6.1ベースの古いカーネルは影響を受けません。端末で「uname -r」を実行して現在のカーネルバージョンを確認し、ディストリビューションのセキュリティ情報と比較してください。Androidの場合、主にPixel 10など、2024年以降にリリースされたカーネルv6.6以降を実行するデバイスが対象となります。

●私のAndroidスマートフォンは危険ですか？今すぐできる対策はありますか？

Androidカーネルv6.1を搭載したPixel 8などは影響を受けません。カーネルv6.6以降を搭載したPixel 10などは影響範囲に含まれます。現在、メモリ破損を誘発するPoCが存在し、完全なrootエクスプロイトが開発中となっています。Googleからセキュリティアップデートが提供され次第、すぐに適用してください。epollは無効化できず、Chromeのレンダラーサンドボックス内からでもトリガーできるため、ブラウザのタブを経由した攻撃の起点となるリスクがあります。

●AIが一方のバグを発見し、Bad Epollを見落としたことは何を意味していますか？

最先端のAIモデルによるコードレビューを経たからといって、そのコードが完全に安全であるとは限らないことを意味します。AnthropicのMythosは、同じ2,500行のepollコードから「CVE-2026-43074」を発見するという優れた成果を上げましたが、その修正によってもう一方のバグ（Bad Epoll）を検出するための実行時シグナル（KASANアラート）が消失してしまいました。セキュリティチームにとって、「AIがレビューした」という事実を過信せず、特に競合状態のような複雑なバグが潜んでいる可能性を考慮することが重要です。

●AIによるセキュリティ研究とパッチ適用の遅れという大きな課題において、Bad Epollはどのように位置づけられますか？

AI支援型セキュリティのボトルネックが、すでに「バグの発見」から「修正能力」へと移行していることを示しています。2026年5月下旬時点で、Project Glasswingが発見した1,596件の脆弱性のうち、修正されたのは約6%（97件）のみです。AIモデルはオープンソースコミュニティが修正できるペースを遥かに上回る速度でバグを発見しており、未修正のまま残されている多くの脆弱性への対応が今後の大きな課題となっています。

元記事: Bad Epoll: Kernel Race Bug Beats AI Auditing, Hits 99% Root Exploit Rate