Description
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.
Published: 2026-10-26
Score: 6.5 Medium
EPSS: n/a
KEV: No
Impact: Bluetooth Stack Crash / Denial of Service
Action: Patch Immediately
AI Analysis

Impact

The vulnerability arises in Zephyr’s Bluetooth Classic Hands‑Free Profile Audio Gateway role when an SDP discovery is initiated but the subsequent RFCOMM channel connection fails. During the failure the entire AG object is cleared while a linked node remains in the SDP client’s pending request list, leaving its pointers zeroed. When the list is later processed a NULL dereference occurs, causing the Bluetooth stack to crash or hang. The fault is a classic NULL dere (CWE‑476) and no attacker control over the written value exists.

Affected Systems

Zephyr Project Zephyr RTOS builds that enable Bluetooth Classic and the HFP Audio Gateway role (CONFIG_BT_CLASSIC and CONFIG_BT_HFP_AG) are affected. No other Zephyr configurations are impacted.

Risk and Exploitability

With a CVSS score of 6.5 the vulnerability is considered moderately severe. The EPSS score is not available, and the vulnerability is not listed in the CISA KEV catalog, indicating no confirmed exploitation. The likely attack vector is a remote Bluetooth device within radio range that advertises an invalid RFCOMM channel; no pairing is required. An attacker could simply broadcast such a device to trigger the crash, resulting in a denial of service of the Bluetooth stack.

Generated by OpenCVE AI on October 26, 2026 at 17:36 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the Zephyr patch commit 18a3243b21ef6298988a3034dbda2704a7ad73a4, which fixes the object wipe issue in hfp_ag_create() and related cleanup
  • If patching is not immediately possible, disable the HFP Audio Gateway role (CONFIG_BT_HFP_AG) or disable Bluetooth Classic entirely to remove the vulnerable code path
  • Configure Bluetooth controllers to reject RFCOMM channel values outside the valid range or employ additional validation of SDP service records before initiating connections

Generated by OpenCVE AI on October 26, 2026 at 17:36 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 26 Oct 2026 18:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Mon, 26 Oct 2026 18:15:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Mon, 26 Oct 2026 16:30:00 +0000

Type Values Removed Values Added
Description 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.
Title Bluetooth Classic HFP AG wipes an object still linked in the SDP request list on connect failure, causing a NULL dereference
Weaknesses CWE-476
References
Metrics cvssV3_1

{'score': 6.5, 'vector': 'CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}

Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-10-26T17:37:10.685Z

Reserved: 2026-08-28T21:11:42.388Z

Link: CVE-2026-82389

cve-icon Vulnrichment

Updated: 2026-10-26T17:35:23.400Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-10-26T17:17:30.757

Modified: 2026-10-26T18:34:17.050

Link: CVE-2026-82389

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-26T18:00:08Z

Weaknesses