Linuxカーネル脆弱性「Bad Epoll」(CVE-2026-46242) への対応まとめ

結論

2026年7月に報じられた Linux カーネルの脆弱性「Bad Epoll」(CVE-2026-46242) について対応状況を整理します。本番サーバーの内部構成や秘匿情報は公開せず、外部から見て意味のある 対応内容だけをまとめています。

Bad Epoll とは

epoll は Linux カーネルが提供する、1つのプロセスで多数のファイルやネットワーク接続の状態変化を 効率的に監視するための仕組みです。Webサーバーやネットワークサービスの多くが内部で利用しています。

Bad Epoll は、この epoll のファイル解放処理(file-release path)に存在する race condition（競合状態）に起因する use-after-free の脆弱性です。 片方の処理が解放したメモリ領域に、もう片方の処理がまだ書き込みを続けてしまう、という 一瞬のタイミングのズレを突くことで、カーネルメモリを不正に書き換え、 一般ユーザー権限から root 権限へ昇格できてしまいます。

元となる不具合は2023年に混入したコードに起因するとされ、3年近く見過ごされてきました。 報道によれば、脆弱なカーネル上では非常に高い確率で権限昇格に成功する実証コードが公開されています。

攻撃の前提条件

この脆弱性はWebから直接届く攻撃ではありません。悪用にはサーバー上で 何らかの形でコードを実行できる状態（すでに侵入されている、あるいは脆弱なアプリ経由でコマンド実行を 許してしまっている状態）が前提になります。つまり「侵入の入り口」ではなく、 侵入後にroot権限まで一気に奪われてしまう「二段目」の脆弱性です。

Docker等のコンテナ技術はホストOSのカーネルを共有する構成が一般的なため、 1つのコンテナ内でコード実行を許してしまうと、この脆弱性を使ってホスト側の root権限まで 奪われる可能性がある点にも注意が必要です。

実施した対応

1. サーバーOSのカーネルバージョンを確認し、ベンダーから提供されている修正済みカーネルへの 更新を進めています（設定変更による回避策は存在しないため、カーネル更新が唯一の恒久対策です）。
2. IPS（不正侵入防止システム）に、この脆弱性に関連する痕跡を検知するシグネチャ (kernel_lpe_bad_epoll)を追加しました。
3. 脆弱性情報をセキュリティ管理台帳に登録し、継続的に監視しています。

IPSで見ているポイント

Bad Epoll 自体はネットワーク越しのリクエストとしては現れないため、WAF/IPS単体で 「攻撃そのもの」を止めることはできません。そのため、IPSでは主に 侵入後にこの脆弱性を使おうとする準備・実行の痕跡を監視しています。

• 既知の実証コード名・関連キーワードを含むコマンド実行やアップロードの痕跡
• epoll関連のカーネルAPI呼び出しを試みるような不審なプロセス起動パターン
• Webアプリ経由でのコマンド実行(RCE)の試み全般（これがそもそもの侵入経路になり得るため）

つまり「Bad Epollを検知する」ためには、その前段にある侵入経路（Webアプリの脆弱性を突く試み） 自体を検知・遮断する既存の防御と組み合わせることが重要だと考えています。

運用メモ

今回のような「侵入後の権限昇格」型のカーネル脆弱性は、ここ数ヶ月で複数報告されています。 1つずつパッチを当てるだけでなく、

• カーネル・OSの更新を定期的に行う
• コンテナやプロセスに必要最小限の権限しか与えない
• そもそもの侵入経路（Webアプリの脆弱性・不審なコード実行）を検知する層を強化する

という多層防御の姿勢を継続していきます。

環境別の詳しい確認手順（スライド）

Ubuntu / Debian / RHEL系 / Oracle Linux / Amazon Linux / SUSE / Docker / Kubernetes など 環境ごとの確認コマンドと対応手順を、下記のスライドにまとめました。 「うちのサーバーはどう確認すればいいか」を調べる際の一覧としてご活用ください。

追記: なぜ検知が難しいのか

この脆弱性の実証コードでは、悪用が成立するタイミングの幅（レースウィンドウ）が わずか6命令程度と非常に狭いことが報告されています。それにもかかわらず、 研究者の検証では脆弱なカーネル上で9割以上という高い確率で権限昇格に 成功したとされています。狙う瞬間は一瞬でも、成功率自体は高いということです。

もう一つ興味深いのは、この不具合が通常のメモリ異常検出ツール(KASAN等)では 検知しにくい構造になっている、という点です。ロックを保持したまま解放後メモリを読む という経路を通るため、検出ツールが構造的に反応しづらいと説明されています。 実際、原因となった2023年のコード変更からは似た系統のバグがもう1件見つかっており、 そちらはAIによるコードレビューで発見・修正済みでした。しかし Bad Epoll 自体は 今回のPoC公開まで見過ごされていました。「AIやツールでレビュー済みだから安全」と 言い切れない一例として、当サイトでも継続的な監視を重視しています。

追記: 主要ディストリビューションの対応状況(2026-07時点)

• Ubuntu: 26.04 LTS / 25.10 / 24.04 LTS が対象。22.04 LTS 以前は対象外。
• Debian: trixie は修正版で対応済み。bookworm / bullseye は該当コード自体が無く対象外。
• Amazon Linux 2023: kernel6.18系は2026-06-22の更新で対応済み。kernel6.12系は本記事執筆時点でまだ対応中。 Amazon Linux 2は対象外。
• Oracle Linux (kernel-uek): 2026-07-02付けの更新で対応済みのバージョンが提供されています。

バージョン番号だけで自環境の安全性を判断せず、お使いのディストリビューションの 公式アドバイザリで「このCVEの修正が入っているか」を確認することをおすすめします。

追記: 当サイトでの対応結果

上記の内容を踏まえ、本番サーバーのカーネルをベンダー提供の修正済みバージョンへ更新し、 再起動して新カーネルで起動していることを確認しました。更新前後で主要サービスの ヘルスチェックにも問題はありませんでした。

影響範囲・出典

最終確認日: 2026年7月22日。Bad Epollはネットワークから直接実行される脆弱性ではなく、 未修正カーネル上でローカルの低権限プロセスが悪用できる権限昇格です。問題はLinux 6.4で導入され、 ベンダーによる修正のバックポート状況を確認する必要があります。 NVD記録と 公開技術報告を参照してください。