Обработчик приема L2CAP Bluetooth Classic (BR/EDR) bt_l2cap_br_recv() в subsys/bluetooth/host/classic/l2cap_br.c отправлял PDU входящих данных только на основе идентификатора канала назначения, не проверяя, достиг ли целевой канал состояния BT_L2CAP_CONNECTED. Динамическому каналу присваивается его CID RX и добавляется в список каналов соединения, пока он еще находится в состоянии BT_L2CAP_CONNECTING (и позже BT_L2CAP_CONFIG) — до завершения настройки и, для PSM, требующих безопасности, до аутентификации однорангового узла (l2cap_br_conn_req()). Поскольку канал уже доступен bt_l2cap_br_lookup_rx_cid() в течение этого окна, удаленный узел в пределах радиодиапазона может отправить PDU данных, адресованный этому CID, и обработать его на еще не установленном канале.
Ключи диспетчеризации полей канала (BR_CHAN(chan)->rx.mode, rx.mps), которые инициализируются только во время настройки с помощью l2cap_br_conf(); поскольку объекты канала объединены в пул и bt_l2cap_br_chan_del() не сбрасывает rx.mode или буфер повторной сборки _sdu, повторно используемый канал может перенести устаревшее состояние в окно CONNECTING и направить кадр в путь повторной передачи/управления потоком (bt_l2cap_br_ret_fc_recv()) с устаревшими параметрами и, возможно, устаревшим указателем _sdu. Результатом является доставка данных злоумышленника обработчикам протоколов верхнего уровня по полуоткрытому (и, возможно, неаутентифицированному) каналу, а также работа с устаревшим или частично инициализированным состоянием канала на повторно используемых объектах канала, что приводит к отключению канала/канала (отказ в обслуживании) и, в случае stale-_sdu, к состоянию висячего указателя. Исправление добавляет явную защиту BR_CHAN(chan)->state < BT_L2CAP_CONNECTED, которая отбрасывает любые полученные данные до полного подключения канала.
Показать оригинальное описание (EN)
The Bluetooth Classic (BR/EDR) L2CAP receive handler bt_l2cap_br_recv() in subsys/bluetooth/host/classic/l2cap_br.c dispatched inbound data PDUs based only on the destination channel ID, without checking that the target channel had reached the BT_L2CAP_CONNECTED state. A dynamic channel is assigned its RX CID and added to the connection's channel list while still in BT_L2CAP_CONNECTING (and later BT_L2CAP_CONFIG) — before configuration completes and, for PSMs that require security, before the peer is authenticated (l2cap_br_conn_req()). Because the channel is already findable by bt_l2cap_br_lookup_rx_cid() during this window, a remote peer within radio range can send a data PDU addressed to that CID and have it processed on a not-yet-established channel. The dispatch keys off channel fields (BR_CHAN(chan)->rx.mode, rx.mps) that are only initialized during configuration by l2cap_br_conf(); since channel objects are pooled and bt_l2cap_br_chan_del() does not reset rx.mode or the reassembly buffer _sdu, a reused channel can carry stale state into the CONNECTING window and route the frame into the retransmission/flow-control path (bt_l2cap_br_ret_fc_recv()) with stale parameters and a possibly stale _sdu pointer. The impact is delivery of attacker data to upper-layer protocol handlers on a half-open (and possibly unauthenticated) channel, plus operation on stale or partially initialized channel state on reused channel objects — leading to channel/link teardown (denial of service) and, in the stale-_sdu case, a dangling-pointer condition. The fix adds an explicit BR_CHAN(chan)->state < BT_L2CAP_CONNECTED guard that drops any data received before the channel is fully connected.
Характеристики атаки
Последствия
Строка CVSS v3.1