2026年7月2日、ソウル大学CompSec LabのPhDリサーチャーJaeyoung Chung氏が、Linux kernelのepoll subsystemに存在するrace-condition use-after-free脆弱性CVE-2026-46242、通称「Bad Epoll」の技術詳細とexploitをGitHub上の技術解説(writeup)で公表しました。同脆弱性はGoogleのkernelCTFプログラムに0-dayとして提出されていたもので、Linux desktop・serverでは通常アカウントで動作するローカルユーザーがroot権限を奪取しうる重大な権限昇格の欠陥です。Androidデバイスも影響対象で、Chung氏はPixel 10のkernel 6.6以降でUAFのtriggerが動作することまで確認していますが、完全なroot exploitはまだ開発途上とされています。修正はupstream commita6dc643c6931として2026年4月24日にmainlineへマージ済みで、Chung氏の技術解説には対応するLTS 6.12.67環境で成功率99％、Container-Optimized OS(COS) 121-18867.294.100環境で98％のexploitが記録されています。
本件が公開直後から広く注目された背景の1つが、AI駆動のコード解析との関係です。Bad Epollを導入した2023年4月8日のカーネルコミット58c9b016e128は、実は2つの独立したrace conditionを同時に持ち込んでいました。Chung氏の技術解説によれば、うち1つはAnthropicのMythosモデルが発見したCVE-2026-43074として2026年4月2日に修正されており、Bad Epoll側は同じepollコードパスを扱った先行研究の後にも自動化された解析には拾われず、Chung氏が独立に発見してexploitまで組み上げた、と整理されています。ただしAnthropic公式のMythos Preview紹介記事は「Linux kernel privilege escalation」の成果一般に言及しているものの、CVE-2026-43074を明示的にリンクしていない点は補足しておく必要があります。同じ狭いコード領域に潜んだ姉妹バグを、AIモデルが片方だけ捕捉し、もう片方は人間リサーチャーが独立に見つけて実際のexploitに至ったという構図が、Bad Epollを単なるkernel LPE以上の題材にしています。
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-46242 |
| 通称 | Bad Epoll |
| 技術解説公開日 | 2026年7月2日(Chung氏のGitHub上の技術解説) |
| 発見者 | Jaeyoung Chung氏(ソウル大学CompSec Lab、PhD researcher)、指導教員Byoungyoung Lee氏 |
| 影響 | ローカル権限昇格(通常アカウント → root) |
| 影響対象 | Linux kernel 6.4以降を含むLinuxデスクトップ・サーバー・Android (kernel 6.1ベースのPixel 8などは影響外) |
| 回避策 | なし(epollはLinuxの基本機能で、停止させる手段がない) |
| Google kernelCTF報奨金 | $71,337以上 |
| 実環境での悪用 | 記事執筆時点で悪用の観測報告なし |
Bad Epollの技術構造
epollのクローズ処理のコードパスで発生するrace condition
epoll(event poll)は、Linuxが高スループットのI/Oイベント監視のために提供するシステムコール群で、ほとんどの現代的なLinuxサービス、ブラウザ、Androidアプリケーションが背後で利用する基本機能です。Chung氏の技術解説が示したBad Epollは、2つのepollファイルディスクリプタが互いを監視するように設定され、双方をほぼ同時にクローズしたときに、カーネル内の2つのコードパスが同じ内部オブジェクトを同時に片付けようとする状況で発生します。一方のパスがすでにメモリを解放したあとに、もう一方のパスがそのメモリ領域に書き込みを行うと、use-after-freeによるkernelメモリ破壊が成立します。
特定の8バイト書き込みを狙って使うと、このUAFは他のカーネルオブジェクト(具体的にはfileオブジェクト)のUAFに格上げでき、そこからcross-cache攻撃(解放済み領域を別のカーネルオブジェクトで再利用する攻撃)で解放領域の内容を攻撃者の制御下に置くことができます。Chung氏の技術解説では、この段階から先はほぼ標準的なkernel exploitの手筋として、/proc/self/fdinfo 経由の任意カーネルメモリ読み取り、関数ポインタの書き換えによる制御フローハイジャック、ROPチェーンによるrootシェルの起動、という順で進んでいく流れが解説されています。
6-instruction race windowと99％成功率のexploit
Chung氏の分析によれば、衝突が成立する命令幅は約6マシン命令で、通常の環境ではスケジューラの通常動作でこのウィンドウに命中する確率は極めて低くなります。同氏の技術解説には、race windowを意図的に広げてから再試行ループでヒットさせる手法や、kernelをクラッシュさせずに繰り返し試行させるための対処が具体的に記述されており、そうした調整の結果としてLTS 6.12.67環境で約99％、Container-Optimized OS 121-18867.294.100環境で約98％という高い成功率が計測されています。
Chung氏はさらに、Bad EpollがChrome renderer sandboxの内部から到達可能である点と、Androidデバイスにも同じコードパスが存在する点を強調しています。多くのLinux kernel LPEはChrome sandbox内から発動できないか、あるいはAndroidでは別のパスとしてブロックされる仕組みがありますが、Bad Epollはそのどちらの境界も越えられる希少な種類のバグです。同氏によれば、Google kernelCTFプログラムに提出された過去のおよそ130件の脆弱性のうち、Androidをrootにできる候補は約10件で、Bad Epollはその1つに数えられます。Pixel 10とその後継のkernel 6.6以降を含む端末ではUAFのtriggerが動作することまで確認済みで、root権限奪取まで到達するexploitは開発途上とされています。一方、kernel 6.1ベースのPixel 8などは影響対象から外れています。
Mythosが見逃した経緯
2023年の同一コミットが導入した2つのrace condition
Chung氏の技術解説には、Bad Epollに至るまでの時系列が詳細に記録されています。2023年4月8日、Linux kernelのepollコードにコミット58c9b016e128が入り、このコミットが結果的に約2,500行のepollサブシステム内に2つの独立したrace conditionを持ち込むことになりました。Chung氏の整理によれば、1つはAnthropicのMythosモデルが発見したとされるもので、CVE-2026-43074として2026年2月頃に報告され、対応するパッチが2026年4月2日にmainlineにマージされました。同氏は、race conditionが人間の熟練監査者にとっても発見が難しい種類の欠陥である点を踏まえると、AIモデルによる発見自体は興味深い成果だと評価しています。ただしAnthropic自身のMythos Preview紹介記事にはCVE-2026-43074への明示的な言及はなく、Chung氏の帰属は同氏側の分析に基づく整理である点は留意が必要です。
一方、Chung氏はほぼ同時期の2026年2月17日に、独立にBad Epollをsecurity@kernel.orgへ報告しています。同氏によれば、初回のパッチプロトタイプは不完全で、Mythosが発見した姉妹バグ側の修正が先にマージされたあとにもBad Epoll側のrace conditionは残っていました。同氏は4月22日に残りの問題を再報告し、2日後の4月24日にa6dc643c6931として修正がmainlineに入りました。同一コミットが2つの独立したrace conditionを導入し、AIモデルが1つを、人間リサーチャーがもう1つを、それぞれ独立に発見する形で解消されるまで約2ヶ月を要した経緯があります。
Chung氏が分析するMythosの見逃し理由
Bad EpollとCVE-2026-43074が同じコード領域に存在した以上、Mythosが同じ範囲を意味のある深さで解析していたと推察されます。にもかかわらずBad Epollを捕捉できなかった理由について、Chung氏はレポート内で2つの仮説を提示しています。あくまで同氏自身が「正確な理由は誰にも分からない」と断ったうえでの推測ですが、race conditionという脆弱性クラスの性質を考えるうえで示唆的な整理です。
- タイミングウィンドウが極端に狭い：Bad Epollの衝突ウィンドウは約6マシン命令幅で、正確なイベントシーケンスをコードから想像しにくい構造になっています。Chung氏は、CVE-2026-43074側のrace windowとの違いが、モデルが「これは実在するバグだ」と評価するかどうかの境界に影響した可能性を挙げています。
- 実行時の証拠がほぼない：CVE-2026-43074が修正されたあと、Bad Epollのメモリエラーは通常のワークロードではKASAN(kernel address sanitizer)を発火させません。Chung氏は、AIモデルが自らの推測を検証しに行こうとしたときに、実行時の証拠がほとんど得られないため、実在するバグとして報告する自信を持てなかった可能性を指摘しています。
Chung氏は技術解説の結びで、Bad Epollが「AIモデルの存在下でも探究に値する脆弱性研究の方向性」を示唆すると述べています。同氏の整理では、race conditionは発見が難しく、正確な修正も難しく(初回パッチは不完全で修正までに2ヶ月かかった)、exploitも6命令幅の窓を掴む必要があるという点で、すべての段階で難易度が高い脆弱性クラスです。狭いタイミング条件と弱い実行時の証拠の背後にある実際のセキュリティインパクトを発見することは、フロンティア級のAIモデルが手元にある状況においても、人間の研究者が引き続き価値を発揮できる領域である、というのが同氏の観察です。
「Bad」ファミリーと近年のLinux権限昇格脆弱性との対比
Bad Epollは、Androidをroot化するために使われてきたkernel bugの系譜である「Bad」ファミリーに連なる名前です。過去にはBad Binder、Bad IO_uring、Bad Spinといった同系統のrace-condition系脆弱性があり、いずれもkernel内部の同期処理の隙を突く形の欠陥でした。Bad Epollはepollという基本I/O機構自体にこの種の欠陥が存在した点で、これらの延長線上に位置します。
ただし、直近のLinux LPEの主流とは性質が異なる点にも触れておく必要があります。2026年に相次いで公開されたCopy Fail (CVE-2026-31431、4月、CISA KEV追加済み)、Dirty Frag chain、Fragnesia、DirtyClone、pedit COWは、いずれもDirty Pipe (2022)の系譜に連なるdeterministicなpage-cache-write型の脆弱性で、実行の再現性が高いのが特徴でした。これに対してBad EpollはDirty Cow (2016)側の系譜、古典的な種類に属します。同じ「Linux LPE」の括りでも、攻撃者側から見た運用の性質はかなり異なります。
Chung氏が指摘するもう1つのポイントが、Bad Epollにはキルスイッチ(無効化手段)が存在しない点です。Copy Failをはじめとする最近のLPEの一部は、脆弱なモジュールをアンロードすれば当該の攻撃面が一時的に閉じますが、epollはネットワークスタックやGUI、ブラウザから広く使われる中核的な機能で、停止させる手段が事実上ありません。ワークアラウンドが取れない以上、対処はカーネルパッチの適用に一本化されます。
影響範囲と修正状況
Bad Epollの影響カーネルは、脆弱性を導入したコミット58c9b016e128が含まれるLinux kernel 6.4以降のバージョン群です。修正はupstreamのa6dc643c6931として2026年4月24日にmainlineへマージ済みで、各ディストリビューションはこのパッチをbackportしたカーネル更新を順次リリースしています。運用中の環境では、以下の3層で対応状況を確認するのが実務的です。
- Linuxディストリビューション：Debian、Ubuntu、RHEL、SUSE、Fedora、Archなどの各ベンダーが公開する セキュリティアドバイザリで、CVE-2026-46242に対応するkernelパッケージのバージョンを確認します。長期サポートkernelを採用しているディストリビューションでは、対応するLTS系列(6.12系など)へのbackport状況が焦点です。
- クラウドプロバイダのmanaged OS：Google Container-Optimized OS(COS)、Amazon Linux、Azure Linux系イメージなど、クラウド事業者が提供するOSイメージのカーネルバージョンと、Bad Epollに対応するパッチの適用状況を確認します。Chung氏の技術解説ではCOS 121-18867.294.100でexploitが動作した実績が示されており、影響対象になりうる範囲は広めに見積もる必要があります。
- Androidデバイス：kernel 6.4以降を採用する端末が影響対象で、6.1系ベースの端末(Pixel 8など)は影響対象外です。Android Security Bulletinにおける対応月次の対応状況と、各ベンダー(Samsung、Google Pixelなど)のsecurity updateリリース状況を追跡します。
対応方針として
Bad Epollに対する実務上の対処は、パッチを含むkernel更新の計画的な適用が基本線になります。多くのLinux LPEと同様に、既にrootを取っている攻撃者にとっての追加価値は限定的ですが、外部からの侵入やsandbox突破と組み合わせたときの威力が問題になります。次のような観点で優先順位を組むのが妥当です。
- マルチテナントホストの優先パッチ適用：Kubernetesワーカーノード、CI/CDランナー、コンテナビルドファーム、共有開発サーバーなど、非特権ユーザーがローカルシェルを持てる環境はBad Epollのリスクが最も高くなる領域です。Chung氏の技術解説が示す通り、raceを勝ち抜くための繰り返し試行はカーネルクラッシュを避けながら実行できる設計になっているため、共有ホスト上での不審なkernelパニック増加を待つよりも、パッチ適用の前倒しが現実的な対処になります。
- ブラウザレンダラーサンドボックス経由の到達性の意識：Bad EpollはChrome renderer sandboxの内部からも到達可能とされる希少なkernel bugです。renderer側の0-dayと組み合わされた場合、悪意あるWebページへの誘導だけでroot権限奪取まで至る攻撃チェーンが成立しうる点は、防御側として想定に入れておく価値があります。ワークステーション側のkernel更新は、サーバー系と同じ優先度で扱うべき理由です。
- Androidフリートの管理：企業支給のAndroid端末や、業務利用BYOD端末について、kernel 6.4以降を採用する機種のAndroid Security Bulletin適用状況を追跡します。Bad EpollのAndroid版exploitは記事執筆時点で開発途上ですが、UAF triggerはPixel 10世代でも確認されており、根本対処は月次security updateに依存する構造です。
- KASAN依存の内部検知プロセスの見直し：Chung氏の分析にあった通り、Bad EpollのメモリエラーはKASANを発火させない特性があります。fuzzingインフラや内部脆弱性検証ワークフローがKASAN発火頼みになっている組織は、race-condition系脆弱性に対する検出能力の見直しに、良いタイミングです。
- ワークアラウンド不在の受容：Bad Epollにはepollを無効にする手段がなく、パッチ適用以外の暫定策は存在しません。パッチが即座に適用できない環境では、そのホスト上での非信頼コード実行を抑える運用上の制約(ローカルシェル発行の絞り込み、コンテナ隔離ポリシーの見直し、SELinux/AppArmorプロファイルの再確認など)を、代替的な緩和策として組み立てます。
まとめ
Bad Epollをより広い文脈から見たときに興味深いのは、同じ2023年のコミットが導入した2つのrace conditionのうち、1つがAI駆動の脆弱性解析(Chung氏の整理ではAnthropic Mythosに帰属されるCVE-2026-43074)によって捕捉され、もう1つが人間リサーチャーの独立発見(Chung氏のBad Epoll)によって捕捉されたという構図です。Chung氏自身が示した仮説は、AIコード解析が現時点で得意な領域と、人間の研究者が独立して価値を発揮できる領域の輪郭を、具体的な事例で示唆するものです。CVEレベルでの重要度に加えて、脆弱性研究におけるAIと人間の役割分担の現在地を考える題材としても、Bad Epollは記録に値する一件になりそうです。
一次情報・公式情報
- Bad Epoll (CVE-2026-46242) 技術解説 (Jaeyoung Chung、2026年7月2日)
- Mythos Preview and Linux Kernel Vulnerability Research (Anthropic Red)
- Linux kernel commit a6dc643c6931 (upstream fix)
- Google kernelCTF Program Rules and Rewards
参考情報
- New “Bad Epoll” Linux Kernel Flaw Lets Unprivileged Users Gain Root, Hits Android (The Hacker News、2026年7月3日)
- Why Is the “Bad Epoll” Linux Kernel Vulnerability Only Making Headlines Now, in Early July? (PBX Science)
slug: bad-epoll-linux-kernel-cve-2026-46242
コメント