セキュリティ脆弱性対応をHermesに任せる——Dirty Fragを例に
Linuxカーネルの重大なローカル特権昇格（LPE）脆弱性「Dirty Frag」（CVE-2026-43284 / CVE-2026-43500）が2026年5月に公開された。エンバーゴ破裂でPoC先行公開という最悪のタイミングだったが、今回これをHermesエージェントと会話しながら対処した経験をもとに、「セキュリティ速報への対応」というタスクをHermesにどう渡すか、具体的な指示の出し方をまとめる。
Hermesに渡したいタスクの全体像
セキュリティ脆弱性対応は、大きく3フェーズに分かれる。
情報収集フェーズでは、CVE番号・技術詳細・影響ディストリビューション・現時点のパッチ状況を把握する。環境診断フェーズでは、自分の環境が本当に影響を受けるかをシェルコマンドで確認する。緩和適用フェーズでは、コストとリスクを比較した上で適切な対処を選んで実行する。
この3フェーズを人間がすべてやろうとすると、複数のブログ・セキュリティアドバイザリ・ディストリのリリースノートを横断して読む必要があり、かなりの時間がかかる。Hermesに適切な指示を出せば、調査から診断コマンド生成まで自動化できる。
基本の指示テンプレート
新しいLinuxカーネルLPE脆弱性「{脆弱性名}」（{CVE番号}）が公開されました。
以下を順番に実施してください。
1. web検索で技術詳細・影響範囲・現時点のパッチ状況を調査する
2. 私の環境（WSL2 / Ubuntu {バージョン} / カーネル {バージョン}）への影響を評価する
3. 即座に打てる緩和コマンドを提示する（副作用も明記）
4. パッチが出た際の完全解決手順を別途提示する
これだけで、TinyFish（Web検索スキル）が走り、調査→評価→コマンド提示まで一気通貫で返ってくる。
Dirty Fragで実際に使った指示と、うまくいった理由
今回の指示はこうだった。
Dirty Frag（CVE-2026-43284 / CVE-2026-43500）について詳細を調べてまとめてください。
WSL2ユーザーへの影響も含めて。
シンプルだが、「WSL2ユーザーへの影響も含めて」という一文が効いた。一般的なLinux向け緩和策をそのまま持ってくるのではなく、WSL2が Microsoft カスタムカーネルを使っていること・モジュール構成が異なること、という文脈を拾って調査してくれた。
調査結果を受けて次の指示を出した。
WSL2環境で以下を確認するコマンドを生成してください。
- esp4/esp6/rxrpcモジュールが現在ロードされているか
- 各 .ko ファイルがカーネルモジュールディレクトリに存在するか
環境固有の診断コマンドを生成させる、という分割が重要だった。「調査」と「診断コマンド生成」を別の指示に分けることで、Hermesが混乱せずに的確なコマンドを出せた。
指示を分割するときの判断基準
一発で全部やらせようとすると、調査の深さが浅くなりやすい。目安はこうだ。
外部情報の取得（Web検索・アドバイザリ読み込み）が必要なフェーズと、ローカル環境への依存（コマンド生成・適用判断）が必要なフェーズは、指示を分けた方がいい。理由は単純で、前者はTinyFishスキルが主体になり、後者は会話コンテキスト（環境情報）が主体になるからだ。混ぜると両方が中途半端になる。
「副作用を明記させる」という習慣
セキュリティ緩和コマンドは、適用することで別の機能を壊すリスクがある。今回で言えば、esp4/esp6をブラックリスト化するとIPsec/VPNが使えなくなる。rxrpcはAFSが使えなくなる。
指示の中に「副作用も明記」と入れるか、あるいは結果を受け取った後に以下を追加する。
このコマンドを適用した場合の副作用・使えなくなる機能を列挙してください。
私の環境でそれらを使っているかどうかも判断してください。
「私の環境でそれらを使っているかどうかも判断してください」という部分がポイントで、HermesはセッションコンテキストからWSL2環境の用途を推測し、IPsec/VPN未使用なら安全、と判断してくれた。
Hermesスキルとして切り出すなら
頻繁に使うなら、セキュリティ脆弱性対応スキルとして切り出すのも手だ。YAMLフロントマターはこんな構成になる。
---
name: security-vuln-triage
description: |
新しく公開されたCVE/LPEに対して、調査・環境診断・緩和コマンド生成を行う。
Web検索スキル（TinyFish）と組み合わせて使用。
triggers:
- CVEが公開された
- 脆弱性の影響を調べてほしい
- 緩和コマンドを生成してほしい
inputs:
- cve_id: CVE番号（例: CVE-2026-43284）
- vuln_name: 脆弱性の通称（例: Dirty Frag）
- env: 環境情報（OS、カーネルバージョン等）
---
スキルのプロンプト本体では、フェーズごとにサブタスクを定義し、TinyFishを使う調査フェーズとローカル依存の診断フェーズを明示的に分離する構成にするとよい。
今回の結論
Dirty Fragへの対処は最終的に1コマンドで完了した。
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf"
rxrpcがWSL2カーネルに含まれておらず、esp4/esp6も未ロードという環境診断があったからこそ、このコマンドを「安全に適用できる」と判断できた。Hermesへの指示を適切に分割し、環境情報をコンテキストとして渡すことで、「ネットで見つけた緩和コマンドを何も考えずに貼る」という危険な手順を踏まずに済んだ。
セキュリティ速報はスピードが求められる。Hermesをうまく使えば、調査から適用判断までの時間を大幅に短縮できる。
CVE-2026-43500（rxrpc側）はまだ未パッチ。カーネルアップデートが来たタイミングで sudo apt upgrade → 再起動 → ブラックリスト削除、という流れで完全解決になる予定。
Discussion