Trend Micro Deep Security Agentに新たに開示された脆弱性により、ローカルの非特権プロセスがエージェント自身のカーネルモジュールを強制的にアンロード・リロードさせることが可能です。この過程で繰り返し発生する監視の空白が生じ、通常はブロックされるコンテンツが検知されないままディスクに書き込まれる恐れがあります。
この発見は研究者によって高深刻度（High）と評価されており、悪用にroot権限やカーネルモジュールの読み込み権限、あるいはrmmodへの直接呼び出しは一切必要ありません。代わりに、エージェント自体に組み込まれた動作回復パスを悪用するものです。
攻撃は研究者が「イベントストーム」と呼ぶものから始まります。これは動作監視パイプラインを圧倒することを目的とした、通常のローカルファイルシステムおよびプロセスアクティビティの持続的な大量発生であるとMatheuzsecurityは述べています。
テストでは、ファイルの書き込み・切り詰め・名前変更、シンボリックリンクの作成と削除、そして急速なfork/exitサイクルといった操作が、Trend Microエージェントを稼働しているホストに対して大量に実行されます。
この問題の中心には2つのカーネルモジュールがあります。1つ目のtmhookは、Trend MicroのlivepatchベースのGeneric Syscall-Hooking Moduleです。システムコールのディスパッチパスをフックし、他のTrend Microコンポーネントが使用する登録APIを提供します。
2つ目のbmhookは動作監視モジュールです。tmhookに依存しており、イベントキューイング、スロットリング、プロセスとファイルシステムの監視を含む動作監視パイプライン全体を実装しています。
イベントストームが十分な圧力を維持すると、エージェント自身のds_am.initプロセスがrmmod bmhookに続いてrmmod tmhookを実行します。これはカーネルのクラッシュではありません。
研究者はbpftraceを使用してexecveとmodule_freeイベントを監視することで原因を特定し、両モジュールのアンロードを開始したプロセスとしてds_am.initを突き止めました。
PoCプロセスが直接rmmodを呼び出すことはありませんでした。特権を伴うアンロードはすべて、Trend Microエージェントの内部回復メカニズムによって実行されました。エージェントのログエントリにenableBLP=1およびthresholdBLP=100への参照があることから、これはループ防止パスである可能性が高いと考えられます。
モジュールは自動的にリロードされますが、アンロードからlivepatchの再適用完了までの窓は測定可能であり、悪用可能であるとMatheuzsecurityは述べています。
観測された1サイクルのカーネルタイムスタンプによると、livepatchの遷移はおよそ19.6秒にわたり、tmhookが完全に不在となる時間は約1.3秒でした。
重要な点は、bmhookがtmhookのlivepatchアンパッチサイクルの完了前に消えるということです。つまり、下位レベルのフック基盤がアンロードを終える前に、動作監視がすでにオフラインになっていることになります。
同じアンロードとリロードのシーケンスが、テスト中に複数の連続サイクルにわたって繰り返されました。これにより、この状態が攻撃者によってオンデマンドで引き起こし可能であり、繰り返し再現できることが確認されました。
最も重要な結果はリロード自体ではなく、その空白の間に何が起きたかでした。クリーンなベースラインテストでは、Trend Microが既知のテストアーティファクトをブロックし、ファイルはディスクに残りませんでした。
同じアーティファクトをbmhookおよびtmhookのリロード窓の間に配布すると、モジュールが復帰した後もディスク上に残存しました。一時的にリロード中のモジュールが自動的に脆弱性となるわけではありません。
この脆弱性の本質は、非特権のローカルワークロードがオンデマンドでその回復パスをトリガーし、結果として生じる空白を利用して、通常であれば製品がブロックまたは削除するコンテンツを書き込める点にあります。
研究で確認された影響を受けるモジュールは、tmhookバージョン1.2.2129およびbmhookバージョン1.2.2120.2129であり、いずれもTrend Micro Deep Security 2022によって署名されており、カーネル6.8.0のUbuntu上で確認されました。
研究者は2026年2月6日にTrend Microへ最初に問題を報告し、当初はカーネルモジュールのサービス拒否として位置づけていました。
4か月にわたる複数回のフォローアップにもかかわらず、CVEの割り当てや修正スケジュールの確認が得られなかったため、保護バイパスの完全な影響を確認した追加テストを経て、2026年6月3日に調査結果が公開されました。公開時点ではCVE識別子はまだ公式に割り当てられていません。
研究者はこのバグをCWE-693（保護メカニズムの失敗）およびCWE-400（制御されていないリソース消費）に分類しています。ローカル限定のスコープ、一時的なアンロード、そして権限昇格やリモートエクスプロイトが証明されていないことから、Criticalの評価には至っていません。
翻訳元: https://cyberpress.org/deep-security-agent-reload-flaw/
