Уровень ATT хоста Bluetooth (subsys/bluetooth/host/att.c) связывает каждый текущий буфер TX ATT с его собственным каналом через статический массив tx_meta_data_storage[] (data->att_chan = chan). Когда последняя ссылка на буфер удаляется, его обратный вызов net-buf Destroy откладывает обработку завершения до системной рабочей очереди (att_tx_destroy -> att_tx_destroy_work_handler -> att_on_sent_cb -> bt_att_sent), где bt_att_sent разыменовывает канал и его контекст ATT (sys_slist_get(&att->reqs)). Когда одноранговый узел отключается, в то время как PDU ATT (уведомление/индикация сервера или любой ответ) все еще находится в пути передачи контроллера, L2CAP разрывает канал в l2cap_chan_del(): он запускает отключенный обратный вызов, а затем освобожденный обратный вызов (bt_att_released), который освобождает слот сегмента канала.
Поскольку текущий буфер удерживается путем передачи соединения, а не в собственной очереди канала, его отложенная работа по уничтожению может выполняться после освобождения канала. Защита att_on_sent_cb, предназначенная для удаления устаревшего обратного вызова, сама разыменовывает мета->att_chan, который теперь представляет собой висячий указатель на освобожденный (и, возможно, повторно используемый) слот плиты. Удаленный узел с соединением ATT может управлять этим, отключаясь во время обычного трафика ATT; для достижения носителя ATT не требуется сопряжение или взаимодействие с пользователем.
В результате происходит чтение/запись освобожденной памяти канала с использованием после освобождения, что приводит к надежному сбою хоста Bluetooth (отказ в обслуживании) и, поскольку слот пластины канала может быть повторно использован, потенциально может повредить действующую память. Исправление делает bt_att_released() NULL поле att_chan каждой записи tx_meta_data_storage[] по-прежнему ссылающейся на канал перед его освобождением, поэтому отложенный охранник замечает NULL-указатель и отбрасывает обратный вызов. Работы по демонтажу и уничтожению выполняются в рабочей очереди кооперативной системы, поэтому обновление массива сериализуется и не требует блокировки.
Показать оригинальное описание (EN)
The Bluetooth host ATT layer (subsys/bluetooth/host/att.c) associates each in-flight ATT TX buffer with its owning channel via the static tx_meta_data_storage[] array (data->att_chan = chan). When a buffer's last reference is dropped, its net-buf destroy callback defers the completion handling to the system workqueue (att_tx_destroy -> att_tx_destroy_work_handler -> att_on_sent_cb -> bt_att_sent), where bt_att_sent dereferences the channel and its ATT context (sys_slist_get(&att->reqs)). When a peer disconnects while an ATT PDU (a server notification/indication or any response) is still in flight in the controller TX path, L2CAP tears the channel down in l2cap_chan_del(): it runs the disconnected callback and then the released callback (bt_att_released), which frees the channel slab slot. Because the in-flight buffer is held by the connection TX path rather than the channel's own queue, its deferred destroy work can run after the channel has been freed. The att_on_sent_cb guard intended to drop the stale callback itself dereferences meta->att_chan, which is now a dangling pointer into a freed (and possibly reused) slab slot. A remote peer with an ATT connection can drive this by disconnecting during routine ATT traffic; no pairing or user interaction is required to reach the ATT bearer. The result is a use-after-free read/write of freed channel memory, reliably crashing the Bluetooth host (denial of service) and, because the channel slab slot may be reused, potentially corrupting live memory. The fix makes bt_att_released() NULL the att_chan field of every tx_meta_data_storage[] entry still referencing the channel before freeing it, so the deferred guard observes a NULL pointer and drops the callback. Teardown and the destroy work both run on the cooperative system workqueue, so the array update is serialized and needs no lock.
Характеристики атаки
Последствия
Строка CVSS v3.1