CVE-2026-99134 in Linux
要約
〜によって VulDB • 2026年10月28日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
mac802154: local->assoc_devにおけるデータ競合とNULLポインタ参照のバグを修正
local->assoc_devは、アソシエーションパス（association path）とアソシエーション応答ワーカーの間で共有されていますが、共通の同期機構がありません。
mac802154_perform_association() はコーディネータへのポインタを保存し、応答を待ちます。そのタイムアウトおよびエラー処理経路では、このポインタがクリアされ、mac802154_associate() に戻ります。これにより、コーディネータオブジェクトが解放される可能性があります。一方、mac802154_rx_mac_cmd_worker() はアソシエーション中フラグを観測し、mac802154_process_association_resp() を呼び出すことがあります。この関数内では assoc_dev が参照（dereference）されます。
ワーカーによるビットテストとハンドラによるポインタの参照は、クリーンアップ処理に対してアトミックではありません。クリーンアップはこの二つの操作の間で assoc_dev をクリアすることがあり、NULL ポインタ参照を引き起こします。あるいは、応答ハンドラがまだそのポインタを使用している間にコーディネータを解放してしまう可能性があります。
記録された結果は同じタイムウィンドウに露出します。assoc_status および assoc_addr はハンドラによって書き込まれますが、アソシエーション中フラグが設定されている間、アソシエーションパスによって読み取られます。そのため、同一リクエストに対する2回目の応答（例えば悪意のあるもの）が、これらの読み取り操作の間に値を置き換え、呼び出し元に整合性のないステータスとアドレスペアを残す可能性があります。
応答ハンドラはコーディネータの拡張アドレスのみを必要とします。assoc_dev をキャッシュされたアドレスに置き換えることで、ポインタの有効期間への依存関係を解消します。キャッシュされたアドレスおよびアソシエーション中フラグには専用の spinlock で保護を加えます。READ_ONCE()/WRITE_ONCE() のペアでは、すべての32ビットアーキテクチャにおいて __le64 型アクセスのアトミック性が保証されません。
wpan_dev->association_lock はここでは再利用できません：nl802154_associate() は rdev_associate() を通じてこのロックを保持しており、mac802154_perform_association() の全体（応答待ちを含む）にわたって保持されます。そのため、そのロックを取得する応答ハンドラは、アソシエーションがすでに放棄した後にのみロックを得ることになります。
ロックを保持しながら、完了状態をリセットし、キャッシュされたアドレスを公開し、アソシエーション中フラグを設定します。応答ハンドラはそのロックを取得し、ビットおよびキャッシュされたアドレスを再チェックして、応答を記録し、ビットをクリアしてから、待機中のプロセスに通知（complete）を行います。これにより、クリーンアップ処理がハンドラの状態確認と完了操作の間に割り込むことが防げます。また、キャッシュされた64ビット値のティアリング（部分的な更新による不整合）も防止されます。
ハンドラは、ウェイクアップされた待機プロセスではなく、自身で完了前にフラグをクリアします：そうでないと complete() がロック保持中に発行され、2回目の応答（例えば悪意のあるもの）が待機中のプロセスよりも先にそのロックを取得し、結果を書き換える可能性があります。したがって、成功を返す待ち処理は、すでにビットがクリアされていることを意味し、成功パスおよびネガティブレスポンスのパスでは直接戻ります。送信エラーおよびタイムアウトのパスでは、assoc_lock を保持した状態でフラグをクリアします。これにより、呼び出し元が既に選択したエラーを返しつつある間に、競合する応答とクリーンアップ処理との直列化が行われます。両方のパスは、同じロックの下で assoc_status および assoc_addr のスナップショットを取得します。
両者のユーザープロセスはプロセスクコンテキストで実行されるため、通常の spinlock で十分です。このロックは完了を待っている間保持されません。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.