Bad Epoll (CVE-2026-46242) を防御側で検証する - パッチ適用確認と権限昇格の検知

2026年5月末に公開され、7月に入って各所で取り上げられている Linux カーネルの脆弱性 CVE-2026-46242（通称「Bad Epoll」）は、epoll イベント通知サブシステムの解放後使用（use-after-free）に起因するローカル権限昇格の欠陥だ。特別なケイパビリティを持たない一般ユーザーが root を奪取できるとされ、公開 PoC は 6.12 系カーネルで約 99% の成功率を報告している。コンテナや共有ホストなど「一般ユーザーは動くが root は渡したくない」環境で影響が大きい。

この記事では 攻撃手順は一切扱わず、防御・検証の観点だけを扱う。すなわち「手元のカーネルが直っているかを確かめる」「この種のローカル権限昇格を監査ログで検知する」を、自分の検証環境で安全に試す。

この脆弱性の要点

• 対象: mainline は Linux 6.4 以降が影響、6.1 以前は非対象。ただしエンタープライズ系ディストリは原因コミットを古い系列へバックポートしているため、uname -r の数字だけでは判断できない。
• 原因コミット: 58c9b016e128（2023-04-08、v6.4 でマージ）。
• 修正コミット: a6dc643c6931（2026-04-24、mainline）。修正では ep_remove() が file->f_lock に触れる前に epi_fget() でファイル参照をピン留めし、__free(fput) ガードで解放漏れを防ぐ。
• 本質: ep_remove() が file->f_lock の下で file->f_ep をクリアした後もその @file を使い続けたため、並行するクローズ処理と競合し解放済みメモリへ書き込みが起きうる。
• 設定による緩和は存在しない: epoll は並行 I/O を扱うほぼ全アプリが使う中核 syscall であり、無効化できない。user namespace や特別なケイパビリティも前提としないため「namespace を絞れば安全」という類の回避策も効かない。よって唯一の根本対策はパッチ適用であり、検証側の仕事は「本当にパッチが当たっているか」の確認と、当たるまでの間の検知に集約される。

Debian のセキュリティトラッカーでは source package linux として追跡され、Trixie は 6.12.95-1 で修正、Bookworm(6.1系)/Bullseye(5.10系) は not affected とされている。

実際に試す

以下はすべて自分が管理するローカル環境・検証用コンテナ／VM のみで実施すること。他者のシステムに対して行ってはならない。ここで扱うのは攻撃ではなく、パッチ状態の確認と検知ルールの動作確認だけである。

前提環境（本稿の確認環境）:

• Ubuntu 24.04 LTS もしくは Debian 13 (Trixie) の VM/コンテナ
• root（sudo）権限は自分の検証機に対してのみ
• パッケージ: auditd、grep、（任意で）カーネルソース

1. カーネルのパッチ適用状況を確認する

まず稼働カーネルのバージョンとディストリを把握する。

uname -r
cat /etc/os-release | grep -E '^(NAME|VERSION)='

uname -r の数字だけでは判断できないため、ディストリのセキュリティ追跡情報で判定するのが正攻法だ。Debian/Ubuntu 系ではインストール済みカーネルパッケージのバージョンを確認する。

# Debian/Ubuntu: インストール済み linux-image の版数
dpkg -l 'linux-image-*' | awk '/^ii/{print $2, $3}'

Debian Trixie なら 6.12.95-1 以降であれば修正済みだ。期待される出力例（修正適用済みの Trixie）:

linux-image-6.12.95-1-amd64  6.12.95-1

RHEL/Rocky/AlmaLinux 系では、ベンダーはバージョン番号を据え置いたまま修正をバックポートするため、rpm の changelog を CVE 名で検索するのが確実だ。

# RHEL系: kernel の changelog に当該 CVE の記載があるか
rpm -q --changelog kernel | grep -i 'CVE-2026-46242' | head

該当行が出れば、そのカーネルパッケージには修正が取り込まれている。何も出なければ、そのビルドには入っていない（＝要アップデート）と判断する。

2. 修正コードのパターンを直接確認する（ソースがある場合）

exploit の成否で判定するのは誤検知（false negative）を招くため危険だ。ソースが手に入るなら、修正が入ったことを示すコードパターンの有無で判定する。修正版では fs/eventpoll.c の ep_remove() 周辺に epi_fget() と __free(fput) が存在する。

# カーネルソースが /usr/src 以下にある場合
SRC=$(find /usr/src -maxdepth 2 -name eventpoll.c -path '*/fs/*' 2>/dev/null | head -1)
echo "checking: $SRC"
grep -nE 'epi_fget|__free\(fput\)' "$SRC"

期待される出力（修正済みカーネルのソース）例:

checking: /usr/src/linux-source-6.12/fs/eventpoll.c
1425:   struct file *file __free(fput) = epi_fget(epi);

epi_fget と __free(fput) の両方が ep_remove() の文脈に現れれば修正済み。両方とも見当たらなければ未修正のコードベースである。

3. auditd でローカル権限昇格の兆候を検知する

パッチ適用までの検知策として、この種の LPE が最終的に狙う「一般ユーザーが実効 UID 0 のシェルを得る」動きを監査する。以下は Bad Epoll に限らずローカル権限昇格全般に効く一般的な検知ルールで、攻撃コードは含まない。

sudo apt-get install -y auditd    # Debian/Ubuntu
sudo systemctl enable --now auditd

ルールを追加する。setuid/setgid を使わずに euid=0 へ遷移する execve（＝カーネル LPE 成功時の典型的な痕跡）と、eventpoll を含むカーネルログを監視対象にする。

# /etc/audit/rules.d/lpe.rules
cat <<'EOF' | sudo tee /etc/audit/rules.d/lpe.rules
## 非特権ユーザーからの setuid 実行以外での特権取得を監視
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k euid0_exec
-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k euid0_exec
EOF
sudo augenrules --load
sudo auditctl -l

正しく読み込まれれば、auditctl -l に上記 2 ルールが表示される。

安全な動作確認（＝攻撃ではない）として、sudo 経由で euid=0 になるコマンドを実行し、監査ログに拾われることを確かめる。

sudo id            # 正当な特権昇格。これがログに残ることを確認する
sudo ausearch -k euid0_exec -ts recent | tail -20

期待される出力（抜粋）:

type=SYSCALL ... syscall=execve success=yes ... uid=1000 euid=0 ... comm="id"
key="euid0_exec"

この状態で、もし将来 sudo を介さずに（＝正当な昇格経路でないのに）euid=0 の execve が記録されたら、それはローカル権限昇格が成立した強い兆候になる。あわせてカーネルログに eventpoll 由来の警告・oops が出ていないかも定期的に確認するとよい。

sudo dmesg | grep -iE 'eventpoll|use-after-free|KASAN' | tail

平常時は何も出力されないのが期待値だ。KASAN 有効のテストカーネルであれば、epoll 周りの UAF が実際に踏まれた際にここへスタックトレースが出る。

片付け

検証用の監査ルールを本番へ持ち込みたくない場合は削除しておく。

sudo rm /etc/audit/rules.d/lpe.rules
sudo augenrules --load

まとめ

CVE-2026-46242 は設定による回避策が存在しないため、防御側の実務は「パッチが本当に当たっているかの確実な確認」と「当たるまでの検知」に尽きる。uname -r の数字ではなくディストリの追跡情報・changelog・修正コードパターンで判定し、auditd で euid=0 への異常な遷移を監視する、という手順はこの脆弱性に限らずローカル権限昇格全般に応用できる。攻撃再現ではなく、自分の環境を守るためにこそ手を動かしたい。

出典（実在確認に用いた一次・二次情報）:

• TuxCare, “Understanding Bad Epoll, a Use After Free That Roots Linux and Android (CVE-2026-46242)” — https://tuxcare.com/blog/bad-epoll-cve/
• Debian Security Tracker, CVE-2026-46242 — https://security-tracker.debian.org/tracker/CVE-2026-46242
• The Hacker News, “New ‘Bad Epoll’ Linux Kernel Flaw Lets Unprivileged Users Gain Root, Hits Android” — https://thehackernews.com/2026/07/new-bad-epoll-linux-kernel-flaw-lets.html