https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 12 Oct 2026 05:51:58 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-19935 <p>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-&gt;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.</p> <p>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() -&gt; l2cap_chan_del() -&gt; 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.</p> <p>The application therefore frees or re-accepts into an object that the system workqueue still holds in its pending list. If th…</p> <p>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-&gt;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.</p> <p>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() -&gt; l2cap_chan_del() -&gt; 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.</p> <p>The application therefore frees or re-accepts into an object that the system workqueue still holds in its pending list. If th…</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-19935