https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 29 Oct 2026 16:33:22 +0000 https://db.gcve.eu/vuln/cve-2026-82389 <p><strong>Affected:</strong> zephyrproject zephyr</p> <p>In the Bluetooth Classic Hands-Free Profile Audio Gateway role, hfp_ag_create() in subsys/bluetooth/host/classic/hfp_ag.c starts an SDP discovery toward the peer, which links the embedded ag-&gt;sdp_param._node into the SDP client&#39;s pending request list in subsys/bluetooth/host/classic/sdp.c. If the subsequent bt_rfcomm_dlc_connect() call fails, bt_hfp_ag_connect() cleaned up by memset()-ing the entire AG object while that node was still linked, and while ag-&gt;slc_work could still be queued on the system work queue. An in-flight SDP discovery cannot be cancelled — bt_sdp_discover_cancel() is declared in the public header but has no implementation — so the request stays in the list with its func, pool and uuid pointers zeroed.</p> <p>The RFCOMM channel passed to bt_hfp_ag_connect() is taken from the peer&#39;s own SDP Hands-Free service record in the normal AG flow (bt_sdp_get_proto_param() performs no range validation, and samples/bluetooth/classic/handsfree_ag feeds the value straight through), so a remote BR/EDR device in radio range that advertises an RFCOMM channel outside the valid range 0x01..0x1e deterministically forces bt_rfcomm_dlc_connect() to fail and reach the wipe. Reading the peer&#39;s SDP record requires no pairing, and the peer can also trigger the failure by dropping the ACL or racing an RFCOMM DLC on the same DLCI at the right moment.</p> <p>When the SDP client next advances its request list, sdp_client_discover() dereferences the zeroed parameters — net_buf_alloc(param-&gt;pool, ……</p> <p><strong>Affected:</strong> zephyrproject zephyr</p> <p>In the Bluetooth Classic Hands-Free Profile Audio Gateway role, hfp_ag_create() in subsys/bluetooth/host/classic/hfp_ag.c starts an SDP discovery toward the peer, which links the embedded ag-&gt;sdp_param._node into the SDP client&#39;s pending request list in subsys/bluetooth/host/classic/sdp.c. If the subsequent bt_rfcomm_dlc_connect() call fails, bt_hfp_ag_connect() cleaned up by memset()-ing the entire AG object while that node was still linked, and while ag-&gt;slc_work could still be queued on the system work queue. An in-flight SDP discovery cannot be cancelled — bt_sdp_discover_cancel() is declared in the public header but has no implementation — so the request stays in the list with its func, pool and uuid pointers zeroed.</p> <p>The RFCOMM channel passed to bt_hfp_ag_connect() is taken from the peer&#39;s own SDP Hands-Free service record in the normal AG flow (bt_sdp_get_proto_param() performs no range validation, and samples/bluetooth/classic/handsfree_ag feeds the value straight through), so a remote BR/EDR device in radio range that advertises an RFCOMM channel outside the valid range 0x01..0x1e deterministically forces bt_rfcomm_dlc_connect() to fail and reach the wipe. Reading the peer&#39;s SDP record requires no pairing, and the peer can also trigger the failure by dropping the ACL or racing an RFCOMM DLC on the same DLCI at the right moment.</p> <p>When the SDP client next advances its request list, sdp_client_discover() dereferences the zeroed parameters — net_buf_alloc(param-&gt;pool, ……</p> https://db.gcve.eu/vuln/cve-2026-82389