Linuxカーネルのソフトウェアブリッジ実装、特にスパニングツリープロトコル(STP)のタイマー処理に影響を及ぼすuse-after-free脆弱性について、概念実証(PoC)コードが公開されました。
この脆弱性により、キューに入れられたSTPタイマーが解放済みのブリッジメモリを指したままになる可能性があり、条件次第では制御フロー乗っ取りのプリミティブを作り出すおそれがあります。
研究者のn132氏とSven Sze氏が、TyphoonPWN 2026においてこの脆弱性を発見・報告したとされており、その成果はLinux権限昇格部門で2位を獲得しました。
問題となっているコンポーネントは、ソフトウェアイーサネットブリッジとSTPの状態遷移を管理するnet/bridge配下のLinuxブリッジドライバー内に存在します。
各ブリッジは、hello_timer、tcn_timer、topology_change_timer、および複数のポート固有のタイマーを含む定期タイマーを保持しています。
これらのタイマーオブジェクトはstruct net_bridgeに組み込まれており、これはブリッジインターフェースの実体であるnet_device内部にプライベートデータとして割り当てられています。
そのため、タイマーの生存期間はこのネットワークデバイスの割り当てと直接結びついています。ブリッジインターフェースが解放される際、STPタイマーのいずれかがまだキューに残っていた場合、カーネルのタイマーサブシステムが後になって解放済みメモリにアクセスしてしまう可能性があります。
この脆弱性は、カーネルSTPが有効化されたブリッジが管理上ダウン状態のままである一方で、接続されたポートがLEARNING状態に遷移した場合に発生します。
公開された情報によると、この遷移は、ブリッジにIFF_UPフラグが立っていない場合でも定期的なSTPタイマーを作動させてしまう可能性があります。根本原因は、通常のインターフェースのシャットダウン処理と、ブリッジを直接削除する処理との間に存在する不整合にあります。
通常のUPからDOWNへの遷移では、ブリッジのndo_stop経路がbr_dev_stop()を呼び出し、続けてbr_stp_disable_bridge()が呼び出されます。
このルーチンはdel_timer_sync()を通じてSTPタイマーを同期的にキャンセルするため、ブリッジ構造体が解放された後にタイマーコールバックが実行されることはありません。しかし、dellink経路を通じてブリッジを削除する場合は、これとは異なる処理経路をたどります。
br_dev_delete()関数はbr_stp_disable_bridge()を呼び出しません。また、デバイスが既にDOWN状態にある場合、unregister_netdevice_many()はndo_stopコールバックを完全にスキップしてしまうことがあります。
結果として、アクティブなSTPタイマーがCPUごとのタイマーベースにリンクされたままの状態で、ブリッジが解放されてしまうケースが生じます。その後、タイマーサブシステムがsoftirqコンテキストでキューを処理する際、カーネルは再利用済みのスラブメモリ内に存在するタイマーオブジェクトを参照してしまう可能性があります。
公開されたPoCは、netlink経由のブリッジ操作およびインターフェース操作を通じて、この不正なタイマー状態を引き起こすために必要な前提条件を実証しています。解放されるオブジェクトはkmalloc-cg-8kスラブキャッシュに紐づいており、この点が悪用における割り当ての再利用を考える上で重要な要素となります。
SSD-Disclosureの指摘によると、この宙に浮いたタイマーが発火すると、タイマーフレームワークはタイマー構造体に格納された関数ポインタを、そのタイマーオブジェクトへのポインタを渡した状態で呼び出します。
攻撃者がコールバック実行前に、解放済みの割り当て領域を制御可能なデータで確実に再利用させることができれば、この状況は制御フロー乗っ取りにつながる可能性があります。
実際の悪用には、それでもカーネルの設定、ヒープの挙動、名前空間の権限、ハードニング機能、さらには攻撃者が関連するネットワーキングオブジェクトを操作できる能力といった要素が関わってきます。
Linuxのメンテナーは、コミット2a00517db8de4be7df3d483b215c5544fb30a191において、この脆弱性のあるライフサイクル処理に対応するパッチを導入しました。この修正が取り込まれる前のカーネルバージョンを実行しているシステムは、影響を受ける可能性があるものとして扱うべきです。
管理者は、パッチが適用されたカーネルリリースへの更新を行うとともに、信頼できないユーザーがネットワーク名前空間やブリッジデバイスを作成・操作できないよう制限し、ブリッジの作成、STP設定、ポート状態の変更、インターフェースの急速な削除に関わる不審なnetlinkアクティビティを監視することが求められます。
ANY.RUNのブラウザ内データ検査で、検知・調査・対応をより迅速に。フィッシングの完全な可視性を獲得し、SOCを強化してMTTRを削減しましょう
翻訳元: https://cyberpress.org/poc-released-linux-kernel-bridge-stp-use-after-free-flaw/
