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

  - Bluetooth:L2CAP:MTUsig net/bluetooth/l2cap_core.c 上で BR/EDR シグナリングパケットを拒否します:l2cap_sig_channel() は、チャネル MTU までの BR/EDR シグナリングパケットを受け入れ、シグナリング MTU(MTUsig)を強制せずに各コマンドをディスパッチします。無線範囲内のBluetooth BR/EDRピアは、ペアリング前にMTUsigより大きく、多くのL2CAP_ECHO_REQコマンドを含む固定チャネルCID 0x0001パケットを送信する可能性があります。実際の無線ストックカーネル実行では、168 個のゼロレングス ECHO_REQ コマンドを含む 1 つの 681 バイトのシグナリングパケットにより、ターゲットに約 220 ms で 168 ECHO_RSP フレームを送信しました。影響:ペアリング前に、無線範囲内のBluetooth BR/EDRピアは、パックされたECHO_REQコマンドを含む1つの681バイトの固定チャンネルシグナリングパケットから168 ECHO_RSPフレームを強制する可能性があります。Linux の BR/EDR シグナリング MTU を仕様の最小値である 48 バイトとして定義し、コマンドがディスパッチされる前に 1 つのL2CAP_COMMAND_REJECT_RSPキャリー L2CAP_REJ_MTU_EXCEEDEDのある大きなシグナリングパケットを拒否します。MTUExceededのBluetooth Core仕様の文言では、拒否識別子はパケット内の最初のリクエストコマンドと一致し、応答のみを含むパケットはサイレントに破棄されると規定されています。Linuxは意図的にその規範から逸脱しています:リモートスタックは応答がドロップされたことを決して知らないため、サイレントに破棄するとピアが非同期になり、最初のリクエストコマンドを見つけるにはMTUsigを越えたコマンドヘッダーをウォーキングする必要があります。つまり、処理するには大きすぎるとすでに判断したパケットからのバイトを処理する必要があります。
    したがって、常に 1 つの拒否を発行し、最初のコマンドヘッダーからの識別子、つまり単一の固定オフセットバイト読み取りを使用します。無制限の BR/EDR シグナリングパーサーと ECHO_REQ 応答パスは両方とも、最初の git インポートまでトレースします。Fixes タグに対して、後で導入するコミットは利用できません。(CVE-2026-53208)

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

検出

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

medium Nessus プラグイン ID 323402

バージョン 1.2