CVE-2026-19935

WysokieCVSS 7.5

Opublikowano: 11/10/2026(UTC)Zaktualizowano: 13/10/2026(UTC)Przetłumaczono: 12/10/2026(UTC)NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko

0.18%

Percentyl 7 - wyżej niż 7% wszystkich znanych CVE

Streszczenie

Podatność w stosie Bluetooth LE Zephyr pozwala zdalnemu, nieuwierzytelnionemu atakującemu na użycie po zwolnieniu (use-after-free) w obsłudze kanałów L2CAP CoC z dynamicznym PSM. Wysyłając ramkę danych, a następnie żądanie rozłączenia, atakujący może spowodować, że kolejka pracy systemu przetworzy pracę wskazującą na zwolniony kanał, co prowadzi do naruszenia pamięci lub uszkodzenia kolejki pracy.

Ocena ryzyka

Ryzyko obejmuje zdalne wykonanie kodu lub awarię systemu (DoS) w urządzeniach z włączonym Bluetooth LE i dynamicznymi kanałami L2CAP. Atak nie wymaga uwierzytelnienia, a jedynie nawiązanego połączenia CoC, co czyni go szczególnie niebezpiecznym w środowiskach z urządzeniami IoT.

Rekomendacja

Należy natychmiast zaktualizować Zephyr do wersji zawierającej poprawkę, która przekierowuje pracę RX kanału do kolejki Bluetooth i dodaje jawne anulowanie rx_work w l2cap_chan_destroy(). Jeśli aktualizacja nie jest możliwa, rozważ wyłączenie dynamicznych kanałów L2CAP (CONFIG_BT_L2CAP_DYNAMIC_CHANNEL) lub ograniczenie zaufanych peerów.

Inne podatności w Zephyr

Zobacz wszystkie

Oryginalny opis (angielski, źródło NVD)

The Bluetooth LE host queues received L2CAP connection-oriented channel (CoC) data for deferred processing through a struct k_work embedded in the channel object (le_chan->rx_work, handler l2cap_rx_process()) whenever the channel uses a dynamic PSM (0x0080-0x00FF). Channel teardown in l2cap_chan_destroy() in subsys/bluetooth/host/l2cap.c cancels the retransmission-timeout work and drains the RX FIFO, but never cancels rx_work. Because that work item was submitted to the system workqueue while HCI receive processing runs on the dedicated Bluetooth RX workqueue (CONFIG_BT_RECV_WORKQ_BT, the default), a queued rx_work item can outlive the channel it points into. A remote, unauthenticated peer with an established CoC channel triggers this by sending a data K-frame immediately followed by an L2CAP Disconnect Request. The K-frame submits rx_work to the system workqueue; because both workqueue threads are cooperative and the Bluetooth RX workqueue runs at the higher priority (K_PRIO_COOP(CONFIG_BT_RX_PRIO) versus CONFIG_SYSTEM_WORKQUEUE_PRIORITY), the pending item cannot run before the following Disconnect Request is processed in le_disconn_req() -> l2cap_chan_del() -> l2cap_chan_destroy(). The stack then invokes the released() callback, which the API documents as meaning the stack has dropped all references and the application may free the channel memory. The application therefore frees or re-accepts into an object that the system workqueue still holds in its pending list. If the memory is freed and reallocated, the workqueue later dereferences a list node and a handler function pointer read from reused memory; if the object is re-used for a later connection, l2cap_chan_add() calls k_work_init() on a still-enqueued work item, corrupting the workqueue's pending list so that unrelated work items are dropped or the queue spins on a looped list. A related variant lets l2cap_rx_process() run concurrently with teardown, racing the net_buf unref of le_chan->_sdu and the clearing of chan->conn. The fix routes the channel RX work to the Bluetooth workqueue - the same context in which every teardown path runs - and adds an explicit k_work_cancel() of le_chan->rx_work in l2cap_chan_destroy(), so no reference to the channel survives the released() callback. Configurations without CONFIG_BT_L2CAP_DYNAMIC_CHANNEL, or that only use SIG-assigned PSMs (EATT 0x0027, OTS 0x0025) which take the inline receive path, are not affected.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS