CVE-2026-82389: Bluetooth Classic HFP AG wipes an object still linked in the SDP request list on connect failure, causing a NULL dereference
In the Bluetooth Classic Hands-Free Profile Audio Gateway role, hfpagcreate() in subsys/bluetooth/host/classic/hfpag.c starts an SDP discovery toward the peer, which links the embedded ag->sdpparam.node into the SDP client's pending request list in subsys/bluetooth/host/classic/sdp.c. If the subsequent btrfcommdlcconnect() call fails, bthfpagconnect() cleaned up by memset()-ing the entire AG object while that node was still linked, and while ag->slcwork could still be queued on the system work queue. An in-flight SDP discovery cannot be cancelled — btsdpdiscovercancel() 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 bthfpagconnect() is taken from the peer's own SDP Hands-Free service record in the normal AG flow (btsdpgetprotoparam() performs no range validation, and samples/bluetooth/classic/handsfreeag 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 btrfcommdlcconnect() 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, sdpclientdiscover() dereferences the zeroed parameters — netbufalloc(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 CONFIGBTCLASSIC and CONFIGBTHFPAG that use the Audio Gateway role are affected.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments using Zephyr Bluetooth Classic in the Hands-Free Profile Audio Gateway role are exposed. The described normal AG flow, including the handsfree_ag sample, obtains the RFCOMM channel from the peer's SDP Hands-Free service record and passes it to the connection routine.
What does an attacker need to do to trigger the issue?
A remote BR/EDR device in radio range can advertise a Hands-Free SDP service record with an RFCOMM channel outside the valid range of 0x01 through 0x1e. This causes bt_rfcomm_dlc_connect() to fail after SDP discovery has linked the AG object's request node.
What is the expected security impact?
The stale SDP request later uses pointers that were cleared during cleanup, resulting in a NULL-pointer dereference. The supplied severity vector indicates high availability impact and no confidentiality or integrity impact.