CyberFix Note
脆弱性・CVE解説

Bad Epoll(CVE-2026-46242)。Linuxカーネルのepollを突く権限昇格とパッチ対応

対象の目安: Linuxサーバーや端末を運用する情報システム・インフラ担当 / 実務

ソウ攻撃・脆弱性リサーチ担当
・ 約11分で読めます
Bad Epoll(CVE-2026-46242)。Linuxカーネルのepollを突く権限昇格とパッチ対応

Bad Epoll(CVE-2026-46242)は、Linuxカーネルの中心的な機能であるepollに見つかった、解放後使用(use-after-free)の脆弱性です。ローカルで動く非特権のプロセスが、カーネル内のメモリ破壊を突いて最終的にroot権限を奪えます。影響はLinuxのサーバーやデスクトップにとどまらず、同じカーネルを土台とするAndroidにも及ぶと報じられています。問題のコードは2023年に混入し、上流のカーネルでは2026年4月24日に修正、2026年5月30日に公開されました。実証コード(PoC)も公開されているため、放置は避けたい脆弱性です。

この記事では、epollがなぜ影響の広い場所なのか、脆弱性がどのような機構で権限昇格につながるのか、そして設定での回避策が無いこの脆弱性に対して、カーネル更新をどう進めるかを、NVDやパッチ情報に基づいて整理します。攻撃の再現手順は扱わず、運用担当が取るべき対応に絞ります。

epollが影響の広い場所である理由

epoll(eventpoll)は、Linuxが備える入出力の多重化の仕組みです。一つのプロセスが多数のソケットやファイルを同時に監視し、読み書きできるようになったものだけを効率よく処理するために使われます。高い同時接続をさばくWebサーバーやプロキシ、データベース、各種のネットワークサービスは、この仕組みを土台にしています。ブラウザのような身近なアプリケーションでも使われます。

epollがこれだけ広く使われているということは、その実装に欠陥があれば、影響もまた広く及ぶということです。しかもepollはカーネルの標準機能で、設定で切り離せません。特定の危険なオプションを無効化する、といった回避策が取れない点が、この脆弱性への対応を難しくしています。同じLinuxカーネルを土台とするAndroidにも影響が及ぶと報じられているのは、この普遍性の裏返しです。

解放後使用がroot権限につながる機構

use-after-freeは、いったん解放したメモリ領域を、解放後にも参照したり書き込んだりしてしまう不具合の総称です。解放された領域には後から別のデータが載るため、そこへの書き込みは本来と違う意味を持つデータの改ざんになり、条件がそろうとカーネルの制御を奪う足がかりになります。

NVDの説明によれば、Bad Epollの核心はepollの後片付けを担うep_remove()にあります。この関数はfile->f_lockを保持したままfile->f_epをクリアしますが、その後も同じ処理の中で対象のファイルを使い続けます。ここで、ファイルの参照が無くなったときに走る別の後始末の経路(__fput())が、空になったf_epを見て監視構造体struct eventpollを解放します。その結果、最初の経路が続けて呼ぶhlist_del_rcu()が、すでに解放されたメモリ(kmalloc-192のスラブ)へ書き込む状態が生まれます。これが解放後使用の実体です。

つまり、二つの後始末の経路が同じ内部オブジェクトをほぼ同時に片付けようとし、片方が解放したメモリへもう片方が書き込む競合状態です。攻撃者はこの競合を、複数のepollのファイル記述子を組み合わせて意図的に引き起こします。競合の時間窓はごく短いものの、実証コードが公開されており、狙って再発させられることが示されています。本記事では、これ以上の具体的な誘発手順や悪用の詳細には立ち入りません。守る側が押さえるべきは、この欠陥が「ローカルで動けばroot奪取に至りうる」という結論です。

あわせて読みたい

ゼロデイ脆弱性とは。検知が難しい攻撃にどう備えるか

影響範囲とCVSSの読み方

CVSS 3.1のベーススコアは7.8で重大度はHighです。これはkernel.orgのCNAによる評価がNVDに掲載されたもので、NVD独自のスコアは提示されていません。ベクトルはAV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hです。ここで目を引くのが、攻撃元区分がローカル(AV:L)で、必要な権限が低い(PR:L)という組み合わせです。CVSSでいうローカルは、脆弱な部分がネットワークから直接届く場所になく、攻撃には対象マシン上でコードを実行できる状態が要る、という意味です。物理的に端末の前にいる必要はなく、SSHでの遠隔ログインや、すでに侵害されたサービスの内側からでも条件を満たします。そこから機密性と完全性と可用性のすべてに高い影響を与えられる、という評価です。

問題のコードは2023年4月8日の変更で混入したとされ、そこから長期間にわたって多くのカーネルへ引き継がれてきました。上流での修正は2026年4月24日、公開は2026年5月30日です。混入から修正まで期間が長いため、安定版やディストリビューションがバックポートしたカーネルにも広く影響しうる点に注意が要ります。TuxCareの解説では、6.12系を土台とするAlmaLinux 10やCloudLinux 10で影響が確認され、5.14系を土台とするAlmaLinux 9やCloudLinux 9も混入コミットのバックポートにより影響を受けるとみられます(再現の確認が進められている段階)。一方、4.18系を土台とする古い世代は影響を受けない見込みとされています。カーネルの系列だけで一律に判断はできないため、自分の環境が該当するかは、使っているディストリビューションのセキュリティアドバイザリで、CVE番号を手がかりに確認するのが確実です。

なお、同じ2023年の混入コミットからは、姉妹関係にあたる別の脆弱性CVE-2026-43074も生まれています。そちらの修正だけではBad Epollは塞がらなかったとされており、片方を当てたから安心とはいえません。発見はGoogle kernelCTFへの提出を通じて行われ、実証コードも公開されています。

注意

AV:Lだから外部から届かない、と判断して更新を後回しにするのは危険です。権限昇格の脆弱性は、単体では踏み台にしにくくても、別のリモートコード実行と組み合わせると「一般ユーザーとしての侵入」を「rootでの完全掌握」へ引き上げます。攻撃の連鎖を断つ意味で、ローカル前提の脆弱性でも優先して更新してください。

唯一の対策はカーネルの更新

Bad Epollには、一般的な配布カーネルで使える実用的な回避策がありません。epollはビルド時に外す以外に無効化できず、ほぼすべてのネットワークサービスが依存しているため、実運用で切り離すのは現実的でないからです。したがって、確実な是正は修正済みカーネルへの更新か、対応するライブパッチの適用に集約されます。進め方の基本は次のとおりです。

カーネル更新の進め方

  1. 1

    稼働中のカーネル版を uname -r で確認し、資産の一覧と照合して対象を洗い出す

  2. 2

    使っているディストリビューションのセキュリティアドバイザリで、CVE-2026-46242 に対応した修正版が出ているかを確認する

  3. 3

    検証環境で修正版カーネルを適用し、業務アプリケーションが問題なく動くかを確かめる

  4. 4

    本番へ展開し、原則として再起動して新しいカーネルで起動する(稼働中カーネルは再起動まで置き換わらない)

  5. 5

    再起動後に uname -r で新しい版で動いていることを確認し、更新済みの記録を残す

多くの環境では、パッケージ更新のあとに再起動して新しいカーネルで起動する必要があります。再起動を伴わないライブパッチの仕組みを使っている場合は、その提供元がこのCVEに対応したパッチを配布しているかを確認します。いずれの方法でも、更新後に実際に修正版で動いているかの確認までを一続きの手順にしておくと、当てたつもりの取りこぼしを防げます。優先順位づけの考え方は、関連記事も参考になります。

あわせて読みたい

脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方

更新までの時間を多層で埋める

修正の適用には検証や再起動の段取りが要るため、全台へ行き渡るまでには時間がかかります。その間の被害を抑えるには、この脆弱性が「ローカルで実行できる状態」を前提にする点を逆手に取り、そこへ至る経路を狭める考え方が効きます。攻撃者が一般ユーザーとしての足場を得る主な入口は、公開サービスの別の脆弱性や、盗まれた認証情報、あるいは正規利用者による内部からの操作です。

更新が行き渡るまでの当面の備え

  • 対象カーネルのサーバーで、不要なローカルシェルやアカウントを棚卸しして減らす
  • 公開サービスの既知の脆弱性を優先的に塞ぎ、リモートからの初期侵入の経路を減らす
  • サービスを最小権限で動かし、共有ホストでは利用者ごとの分離を見直す
  • 権限昇格や見慣れないプロセスの挙動を検知できるよう、ログと監視を確認する
  • 修正版カーネルの適用計画に期限を設け、進捗を追跡する

これらは脆弱性そのものを直す対策ではなく、修正が行き渡るまでの時間を埋める補助です。最小権限やサーバーの堅牢化、ログ監視といった土台がしっかりしているほど、権限昇格の脆弱性が一つ残っていても、全体を掌握されるまでの障壁は高くなります。守りを一枚の壁に頼らず、複数の層で重ねる考え方が、こうした脆弱性への地力になります。

あわせて読みたい

最小権限の原則(Least Privilege)。なぜ権限を絞ることが最強の防御の一つなのか

CVSS 3.1のベーススコア7.8(High)とベクトルAV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H、eventpollの解放後使用という脆弱性の説明、ep_remove()file->f_lock保持下でfile->f_epをクリア後も対象ファイルを使い続け__fput()との競合で解放済みメモリ(kmalloc-192)へ書き込むという機構、公開日が2026年5月30日であることはNVDのCVE-2026-46242の記載に基づきます(CVSSの採点はkernel.orgのCNAによるものがNVDに掲載されています)。混入が2023年4月8日、上流での修正が2026年4月24日であること、姉妹脆弱性CVE-2026-43074が同じ混入コミットに由来し単独の修正では塞がらないこと、AlmaLinux/CloudLinuxの世代ごとの影響の見立て、設定による回避策が無くカーネル更新が唯一の対策であることはTuxCareの解説に基づきます。ローカルの非特権ユーザーがroot権限を得られること、Androidにも影響が及ぶことはThe Hacker NewsおよびSecurity Affairsの報道に、Google kernelCTFへの提出を通じた発見と実証コードの公開は研究者リポジトリ(J-jaeyoung/bad-epoll)の公開情報に基づきます。各バージョンの該当可否は執筆時点の情報であり、実際の影響は各ディストリビューションのアドバイザリで確認してください。

Bad Epoll(CVE-2026-46242)は、Linuxのどこにでもあるepollという機能に長く潜み、ローカルの一般ユーザーからroot権限への昇格を許す脆弱性です。設定での回避策が無い以上、対策は修正済みカーネルへ更新して再起動し、新しい版で動いていることまで確認する、という一続きの手順に尽きます。全台へ行き渡るまでは、ローカル実行の足場を与えない工夫と、最小権限やログ監視といった多層の備えで時間を埋めます。ローカル前提の脆弱性でも、別の侵入と連鎖すれば被害は一気に広がります。優先度を上げて、着実に更新を進めてください。

出典・参考

この記事をシェア

関連する記事

防御・ハードニング

最小権限の原則(Least Privilege)。なぜ権限を絞ることが最強の防御の一つなのか

必要最小限の権限だけを与える「最小権限の原則」を、なぜ効くのか(侵害時の被害局所化・横展開の抑止)という原理から噛み砕き、過剰権限の典型例とRBAC・ジャストインタイム権限・定期棚卸しといった実践、ゼロトラストとの関係までを実務目線で整理します。