Bad Epoll(CVE-2026-46242)とは - Linux カーネル epoll の権限昇格脆弱性と、AI が見逃した競合バグを読み解く

Linux カーネルの中核である epoll サブシステムに、ローカルの一般ユーザーが root を奪える use-after-free 脆弱性が見つかりました。名前はBad Epoll、CVE 番号はCVE-2026-46242です。サーバ・デスクトップだけでなく Android にも波及するうえ、「同じ 2023 年のカーネルコミットが 2 つの競合バグを同時に埋め込み、そのうち片方を Anthropic の AI モデルが発見しながら、この Bad Epoll だけを見逃していた」という逸話が、7 月に入って一気に話題を呼びました。

当ブログではこれまで、SharePoint Server の RCE 脆弱性 CVE-2026-45659 や Node.js の TLS ホスト名検証バイパス など、実務に効く脆弱性解説を追ってきました。今回は毛色が異なり、アプリ層ではなくカーネルの競合状態(race condition)が主役です。本記事では、確認できた一次〜準一次情報だけをもとに、何が起きているのか、そして運用者・エンジニアが何をすべきかを整理します。

概要(まず結論)

• 何が: Linux カーネルの epoll(eventpoll)サブシステムにおける use-after-free 脆弱性。
• CVE: CVE-2026-46242(通称 Bad Epoll)。
• 種別: 競合状態(race condition)に起因する use-after-free(CWE-416)。
• 深刻度: NVD 掲載の CVSS 3.1 で 7.8(High)。ベクトルは AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H。
• 影響: ローカルの非特権ユーザーが root へ権限昇格できる。サーバ・デスクトップ・Android が対象。
• 対策: 恒久対策はカーネルパッチの適用のみ。epoll は無効化できないため、実質的なワークアラウンドは無いとされる。
• 状況: 修正は 2026 年 4 月に静かにメインラインへ入り、7 月初旬に技術詳細とともに広く報じられた。

まず要点だけ言えば、ディストリビューションが配布するカーネル更新を当てることが唯一かつ最優先の対策です。設定変更で回避する類の脆弱性ではありません。

前提: epoll と file descriptor をおさらい

Linux で多数の接続を効率よくさばくための仕組みが epoll です。Web サーバや各種イベントループが、大量のfile descriptor(ファイルディスクリプタ、以下 fd。カーネルが開いているファイルやソケットを識別する整数)を「どれか読み書き可能になったか」を安価に監視するために使います。epoll_create で epoll 用の fd を作り、epoll_ctl で監視対象の fd を登録し、epoll_wait でイベントを待つ、という流れです。

ここで重要なのは、epoll のインスタンス自体もひとつの fd であり、別の epoll から監視対象として登録できるという点です。つまり epoll が epoll を見張る、入れ子の構造が作れます。この自由度が、今回の脆弱性の土台になっています。

epoll の内部では、監視対象の fd(を表す struct file)と epoll インスタンスが相互にポインタで結び付けられます。登録・解除のたびに、この結び付きを整合性を保ちながら張り替える必要があります。マルチコアで複数スレッドが同時に登録解除や close を行うと、この張り替えの最中に別スレッドが割り込む余地が生まれます。

脆弱性の仕組み: ep_remove() の競合状態

Bad Epoll の核心は、epoll の登録解除を担う ep_remove() という関数にあります。NVD の記述を借りると、この関数は次のような手順で問題を起こします。

• ep_remove() は file->f_lock というロックの下で file->f_ep(その file が属する epoll への参照)をクリアする。
• ところがクリアした後も、同じクリティカルセクションの中で当の @file を使い続けている。具体的には hlist_del_rcu() や spin_unlock() の処理で、すでに手放したはずの file を触ってしまう。
• ちょうどその瞬間に、別スレッドがその file の参照カウントを落として close を完了させると、file(と関連する eventpoll 構造体)が解放される。
• 結果、ep_remove() は解放済みのメモリを指すポインタを読み書きする。これが use-after-free です。

use-after-freeとは、いったん解放(free)したメモリ領域を、その後も有効なつもりで参照(use)してしまうバグの総称です。解放後の領域は別の目的で再利用されうるため、攻撃者がそこへ都合のよいデータを流し込めれば、カーネル内のポインタや制御フローを乗っ取る足がかりになります。

そしてこの解放とアクセスが「ほぼ同時」に起きるかどうかは、スレッドの実行タイミング次第です。こうした「実行順序のわずかなずれで結果が変わる」不具合を競合状態(race condition)と呼びます。今回のように「チェックしてから使うまでの隙に状態が変わる」構図は、より狭義には TOCTOU(Time-of-Check to Time-of-Use)と呼ばれる古典的なパターンの一種です。

トリガーの直感的なイメージは、2 つの epoll fd を互いに監視させ、それらをほぼ同時に close するというものです。相互参照した状態で解放処理を競わせることで、片方が「まだ生きている」と思い込んだまま、もう片方が解放を完了させる瞬間を突きます。

攻撃の全体像としては、4 つの epoll オブジェクトを 2 組のペアに束ね、一方のペアで競合を起こし、もう一方を犠牲(victim)オブジェクトにする手法が報じられています。解放された領域に生じる 8 バイトの use-after-free を、/proc/self/fdinfo 経由のカーネルメモリ読み出しへ広げ、最終的に ROP(Return-Oriented Programming)で制御フローを奪って root を取る、という流れです。本記事では悪用を助長しないため、これ以上の手順や実コードには踏み込みません。

影響範囲: カーネルバージョンと Android

NVD が示す影響を受けるメインライン系のバージョン範囲は、おおむね次のとおりです(バッククォート内は「この版から、この版未満まで」の意味)。

• 5.15.209 から 5.16 未満
• 6.1.175 から 6.2 未満
• 6.4 から 6.18.33 未満

報道では「6.4 以降のカーネルを使う多くのディストリビューションが対象」「5.10 台から 6.11 台までが確認済み」といった表現も見られますが、各社で確認済みとされる範囲に幅があり、自環境が該当するかは後述の方法で個別に確認するのが確実です。厳密な下限・上限の一次確定は本記事では避け、NVD の範囲を基準として扱います(細部は要確認)。

問題のコードは、報道によれば 2023 年 4 月 8 日のコミット(58c9b016e128)で混入し、2026 年 4 月 24 日のコミット(a6dc643c6931)で修正されました。つまり約 3 年にわたって存在していた計算になります。

見落とせないのが Android です。Android のカーネルは Linux メインラインをベースにしているため、6.6 系以降のカーネルを積む端末が影響を受けるとされ、報道では現行の Pixel も対象に挙げられています。スマートフォンでも「アプリのサンドボックスから抜けて端末を掌握する」踏み台になりうる、という意味で影響は広範です。

AI が片方を見つけ、もう片方を見逃した話

この脆弱性が単なる 1 件の権限昇格を超えて話題になったのは、AI コードレビューが絡むからです。報道を総合すると、経緯はこうです。

問題の 2023 年のコミットは、epoll のコード(全体でおよそ 2,500 行規模とされる)に2 つの別々の競合状態を同時に埋め込んでいました。隣り合う 2 つのバグです。

• 一方の競合(CVE-2026-43074)は、Anthropic の AI モデルMythosが「Project Glasswing」の枠組みでカーネルコードをレビューする中で発見し、2026 年 4 月 2 日にメインラインで修正されました。NVD によれば、こちらは ep_free() が別スレッドから使用中の eventpoll 構造体を kfree してしまう use-after-free で、RCU コールバックへ解放を遅延させる形で修正されています。
• ところがもう一方、つまり Bad Epoll(CVE-2026-46242)は Mythos が見逃していました。最初の修正では第 2 の競合が閉じられず、発見者の Jaeyoung Chung 氏が 4 月 22 日に残る欠陥を再報告し、正しい修正がその 2 日後(4 月 24 日)に入りました。

この Mythos は、当ブログでも取り上げた Anthropic の「Mythos クラス」 のモデルです(Fable 5 / Mythos 5、Project Glasswing)。フロンティア AI がカーネルの競合バグを実際に見つけられるようになったという意味で象徴的な一件でしたが、同時にその限界も突きつけました。

なぜ Mythos は隣のバグを見逃したのか。報道が挙げる理由は主に 2 つです。

1. 競合ウィンドウが極端に狭い。「約 6 命令幅」しかなく、脆弱なコードを見ても、どのスレッド割り込みで壊れるのかを想像しづらい(この「6 命令」は各報道による表現)。
2. 実行時の痕跡が乏しい。CVE-2026-43074 を修正した後だと、Bad Epoll の use-after-free はカーネルの主要なメモリエラー検出器である KASAN(Kernel Address Sanitizer)を発動させにくく、動的解析でも手掛かりが残りにくい。

発見者の Jaeyoung Chung 氏は、ソウル大学(Seoul National University)CompSec Lab の博士課程で、Linux / Android カーネルの並行性バグを研究している人物です。Bad Epoll は同氏によって Google の kernelCTF へ 0-day として提出された、とされています。

対策: パッチ適用と確認方法

繰り返しになりますが、恒久対策はカーネルパッチの適用のみです。epoll は OS やブラウザの中核機能に使われており無効化できないため、機能を止めて回避する類のワークアラウンドは存在しないとされています。

まず、稼働中のカーネルバージョンを確認します。

# 稼働カーネルのバージョンを確認する(例: 6.8.0-xx-generic)
uname -r

得られたバージョンを、前掲の NVD の範囲や利用中ディストリビューションのセキュリティ勧告と突き合わせます。該当しそうなら、パッケージマネージャでカーネルを更新します。以下は一般的な手順の例です(実運用では必ずディストリビューションの勧告に従ってください)。

# Debian / Ubuntu 系: カーネルを含めてパッケージを更新する
sudo apt update && sudo apt full-upgrade
 
# RHEL / Fedora 系: カーネルパッケージを更新する
sudo dnf upgrade --refresh kernel
 
# 更新後は新しいカーネルで起動するために再起動が必要
sudo reboot

補足として、実務上の勘所をいくつか挙げます。

• 再起動が必須: カーネル更新はパッケージを入れただけでは効きません。新カーネルで起動して初めて有効になります(live patch を導入している環境は各ベンダの手順に従う)。
• ロングタームカーネルほど確認を: LTS 系や、ベンダが独自にメンテナンスするカーネルは、メインラインの修正がバックポートされるまで時間差があります。「新しめだから安全」とは限りません。
• Android は端末更新に依存: 端末側は OEM のセキュリティ更新を待つ必要があり、ユーザー側で個別にパッチを当てるのは容易ではありません。提供され次第、速やかに適用してください。
• 多層防御: 権限昇格はまず「ローカルで任意コードを動かせる足場」を必要とします。一般ユーザーアカウントの棚卸し、不要なローカルシェルの排除、コンテナやサンドボックスの境界強化は、この種の脆弱性の悪用ハードルを上げます。国内の動向は 2026 年の主要セキュリティインシデントまとめ もあわせて参照してください。

まとめ

• CVE-2026-46242(Bad Epoll)は、Linux カーネル epoll の ep_remove() に潜む競合状態由来の use-after-free で、ローカルの非特権ユーザーが root へ昇格できる。NVD の CVSS は 7.8(High)。
• トリガーは相互に監視させた epoll fd をほぼ同時に close すること。攻撃者はタイミングの窓を安定化させ、各報道では約 99% の成功率とされる(数値は環境依存・各報道による)。
• 影響はサーバ・デスクトップに加え Android(6.6 系以降、現行 Pixel を含むとの報道)にも及ぶ。恒久対策はカーネルパッチの適用のみで、ワークアラウンドは無い。
• 話題性の核は AI レビューの逸話。同じ 2023 年のコミットが混入させた 2 つの競合のうち、隣の CVE-2026-43074 は Anthropic の Mythos が発見したが、Bad Epoll は見逃した。狭い競合ウィンドウと KASAN が出にくい性質が、AI にとっての盲点になった。
• 対応は uname -r で版を確認し、ディストリビューションの更新を当てて再起動する、という基本の徹底に尽きる。

バージョン範囲の厳密な下限・上限や、発見者・報道各社で表現差のある数値は、本記事では「要確認」「各報道による」と明示しました。確定情報は NVD と、利用中ディストリビューション(および Android なら OEM)のセキュリティ勧告でご確認ください。