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

  - Bluetooth:2 番目の LE 接続が拒否された場合、hci_conn を漏洩しません create_le_conn_complete() は、失敗した接続がまだ保留中かどうかを hci_lookup_le_connect() と比較して判断します。これにより、BT_CONNECT で最初の LE 接続が返されます。これは、最大 1 つが保留中である間のみ同じ接続です。2 つは保留中です。パッシブスキャンパスで作成された接続は、HCI_CONN_SCANNINGが設定された状態でBT_CONNECTされ、コマンドが発行されたときにhci_le_create_conn_sync()がフラグをクリアするまでhci_lookup_le_connect()に表示されません。したがって、hci_connect_le()の-EBUSYガードは、最初の接続がまだスキャンパス上にある間、2番目の接続がキューに入れられるのを防止しません。2 つの接続が同時にBT_CONNECTされると、検索は create_le_conn_complete() がもう 1 つの接続の失敗を報告している間に、一方の接続を返すことがあります。早期に終了すると、エラーは破棄され、失敗した接続では hci_conn_failed() が実行されることはありません。また、コアスペック Vol 4 パート E に従って、別の接続作成が未解決の間に発行された 2 つ目のHCI_OP_LE_CREATE_CONNもコントローラーは拒否します。仕様では、そこでコマンドが許可されないことが求められています。ここで観察された bcm43438 は、代わりに LMP/LL エラーコードで応答します。これは bt_to_errno() 以下のログの -EPROTO (-71) にマッピングされます。漏洩した接続は永遠にBT_CONNECTに残り、hci_lookup_le_connect() が何かを検出している間に hci_connect_le() がダイヤルを拒否するため、その後いずれかのピアに到達しようとする試みは -EBUSY で失敗し、コマンドがコントローラーにまったく到達しません。2つのBLEピアが同じ間隔でポーリングされるbcm43438で見られる(状態5はBT_CONNECT、両方のハンドルはUNSETのもので、上記のidaから割り当てられたHCI_CONN_HANDLE_MAX):Bluetooth:hci1:Opcode 0x2013失敗:-71 # hcitool con < LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL < LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL 次の 10 分間の接続試行の btmon キャプチャには、HCI_OP_LE_CREATE_CONNはまったく含まれません。発信 LE 接続は、アダプターがリセットされるまで回復しません。この変更により、同じシナリオでも拒否された接続が正常に失敗し、両方のピアへの接続がさらに確立されます。デバイスについてではなく、接続自体について尋ねます。(CVE-2026-90087)

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

検出

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

medium Nessus プラグイン ID 347603

バージョン 1.10