CVE-2026-82389 in Zephyr
Summary
by MITRE • 10/26/2026
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->sdp_param._node into the SDP client'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->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.
The RFCOMM channel passed to bt_hfp_ag_connect() is taken from the peer'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'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.
When the SDP client next advances its request list, sdp_client_discover() dereferences the zeroed parameters — net_buf_alloc(param->pool, …) with a NULL pool and param->uuid->type — and the result-notification paths call through the NULL params->func. Zeroing a linked node also truncates the request list behind a stale tail pointer, and re-arming the freed AG slot re-appends the same node and can produce a self-looping list that hangs the Bluetooth RX thread. The impact is a crash or hang of the Bluetooth stack; the written value is a constant zero at a fixed static address, so no attacker-controlled write is available.
Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_HFP_AG that use the Audio Gateway role are affected.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability resides in the implementation of the Hands-Free Profile Audio Gateway functionality within Bluetooth Classic stacks, specifically affecting systems configured with both classic support and hands-free audio gateway capabilities. The core issue stems from a race condition and improper state management during connection establishment procedures. When an Audio Gateway initiates a connection to a peer device, it triggers Service Discovery Protocol operations by calling hfp_ag_create(), which links the internal service discovery parameter node into a pending request list managed by the SDP client subsystem. This linkage is critical for tracking ongoing asynchronous discovery tasks that must complete before higher-layer profile logic can proceed safely.
A critical flaw occurs when the subsequent RFCOMM data link connection attempt fails due to remote device behavior or network conditions. In such failure scenarios, the bt_hfp_ag_connect() function executes a cleanup routine that zeroes out the entire Audio Gateway object structure using memset operations. However, this zeroing process does not properly unlink the SDP parameter node from the pending request list nor cancel the in-flight service discovery transaction. Since the underlying stack lacks an implemented cancellation mechanism for active SDP discoveries, the stale pointer remains embedded within the client's internal data structures despite the parent object being effectively destroyed and its memory contents cleared to zeros.
The vulnerability is exploitable by any remote Bluetooth device operating within radio range that advertises a Hands-Free service record containing an RFCOMM channel number outside the valid operational range of one through thirty. Because standard SDP parsing routines do not perform strict validation on these channel identifiers, feeding such invalid values directly forces the lower-layer connection establishment to fail deterministically. This failure path is triggered without requiring any prior pairing or authentication, allowing unauthenticated attackers to induce the vulnerable state simply by advertising malformed service records or manipulating link layer connections during active setup phases.
The consequences of this memory corruption manifest as severe stability issues within the Bluetooth protocol stack. When the SDP client subsystem later attempts to process its queue of pending requests, it encounters nodes with nullified function pointers and pool references. Attempting to allocate network buffers using a NULL pool pointer or accessing UUID type information from zeroed structures leads to immediate kernel panics or segmentation faults. Furthermore, because the cleanup routine fails to remove the node from the linked list structure, subsequent re-initialization of Audio Gateway resources can result in double-linking of the same memory block. This creates circular references within the request queue that cause infinite loops during list traversal operations, effectively hanging the Bluetooth receive thread and rendering the entire wireless subsystem unresponsive until a system reboot occurs.
Mitigation strategies must focus on rigorous state management and input validation at multiple layers of the protocol stack. Developers should implement proper cancellation logic for in-flight service discovery transactions before destroying associated context structures to prevent dangling pointers from persisting in global queues. Additionally, strict range checking must be applied to all RFCOMM channel identifiers extracted from peer SDP records to reject malformed values early in the connection process rather than allowing them to propagate into lower-layer drivers where they cause deterministic failures. Ensuring that cleanup routines explicitly unlink data structures from active lists before zeroing memory is essential for preventing list corruption and subsequent denial of service conditions caused by circular references or null pointer dereferences during asynchronous callback execution paths.