Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - Bluetooth:hci_uart:close パスと init パスの UAF および競合状態を修正します hci_uart のライフサイクル管理に、use-after-free(UAF)および Null ポインターデリファレンス(NPD)状態につながる脆弱性が観察されました。主な問題が発生する原因は、作業キュー(init_ready および write_work)は、TTY クローズ中に HCI_UART_PROTO_READY フラグが設定されている場合のみ、フラッシュ/キャンセルされるためです。セットアップが完了する前にハングアップが発生した場合、hci_uart_tty_close() はこれらの作業キューの切断をスキップし、「hu」構造体の解放に進みます。スケジュールされた作業が後で実行されるとき、解放された「hu」構造体が盲目的に逆参照されます。
    さらに、いくつかのデータ競合とUAFがティアダウンシーケンスで特定されました:1.write_workを効果的に無効にせずにhci_uart_close()からhci_uart_flush()を呼び出すと、競合状態が発生し、両方が同時にhu->tx_skbを二重解放する可能性があります。これは、プロトコルタイマーが同時に hci_uart_tx_wakeup() を呼び出し、write_workを再キューできるために発生します。2. hu->proto->close(hu)の前にhci_free_dev(hdev)を呼び出すと、ベンダー固有のプロトコルのcloseコールバックがhu->hdevを逆参照するときにUAFが発生します。3.
    初期化エラーパスで、PROTO_READYをクリアする前にproto_lock書き込みロックに失敗すると、アクティブなリーダーとの競合が発生します。さらに、hci_uart_tty_receive()は読み取りロック外のhu->hdevにアクセスするため、初期化エラーパスがhdevを同時に解放する場合、UAFが発生します。これらの同期およびライフサイクルの問題を以下により修正します。1. hci_uart_tty_close() の順序を変更して、最初に HCI_UART_PROTO_READY をクリアし、その後すぐに cancel_work_sync(&hu->write_work) を消去します。フラグを削除すると、同時プロトコルタイマーが正常に hci_uart_tx_wakeup() を呼び出せなくなります。これにより、キャンセルが効果的に永続的になり、tx_skbの二重解放が防止されます。2. 注:PROTO_READY早期にクリアすると、hci_uart_close() が hu->proto->flush() をスキップします。hu->proto->close()がすぐに実行され、本質的にすべてのプロトコルのSKBキューがパージされ、状態が破棄されるため、これはtty_closeパスで完全に安全です。3. ベンダーレベルの UAF を防ぐために、すべてのクローズ パスとエラー パスで hu->proto->close(hu) を hci_free_dev(hdev) より厳密に再配置します。4. hci_uart_tty_receive() の hdev->stat.byte_rx インクリメントを proto_lock 読み取り側の重要セクション内で移動し、デバイスの登録解除と安全に同期します。5. cancel_work_sync(&hu->write_work) を hci_uart_close() に追加して、HCI コア経由で hci_uart_flush() が呼び出される前に作業キューを安全にフラッシュします。6. ユーザー空間の再試行機能が永久に中断されるのを防ぐために、すべてのパスで disable_work_sync() ではなく cancel_work_sync() を使用する。
    (CVE-2026-46275)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

検出

Linux Distros のパッチ未適用の脆弱性: CVE-2026-46275

high Nessus プラグイン ID 319698

バージョン 1.13