Description
bt_hfp_hf_connect() in subsys/bluetooth/host/classic/hfp_hf.c allocates the per-connection HFP Hands-Free object with hfp_hf_create(), which starts an SDP discovery by passing the object's embedded hf->sdp_param to bt_sdp_discover(). That call links the caller-owned parameter block into the SDP client's request list (session->reqs in subsys/bluetooth/host/classic/sdp.c). If the subsequent bt_rfcomm_dlc_connect() then failed, the affected code wiped the entire object with (void)memset(new_hf, 0, sizeof(*new_hf)) while that discovery was still outstanding, zeroing the sys_snode_t _node that is still linked in the SDP client's list along with the request's func, uuid and pool pointers, and zeroing the hf->slc_work work item that may already be queued on the system workqueue. The discovery could not be retracted instead: bt_sdp_discover_cancel() is declared in include/zephyr/bluetooth/classic/sdp.h but has no implementation.

The failing branch is reachable with peer-supplied input. The documented use of bt_hfp_hf_connect() is to pass the RFCOMM channel read out of the remote Audio Gateway's SDP record; neither bt_sdp_get_proto_param() nor bt_hfp_hf_connect() range-checks that value, so a remote device advertising an HFP AG record with an RFCOMM channel outside 1-30 makes bt_rfcomm_dlc_connect() return -EINVAL and drives the local device into the wipe. The same branch is reached without any application misuse when the remote peer controls connection timing, for example when the RFCOMM session is in BT_RFCOMM_STATE_DISCONNECTING or the ACL is dropped between object creation and the RFCOMM call.

Once the object has been wiped, the Bluetooth host continues to use it: sdp_client_alloc_buf() dereferences session->param->pool, which is now NULL, and the SDP receive paths call session->param->func() through a null function pointer, neither of which is NULL-checked. Because the wipe also clears hf->acl, the pool slot is considered free and a retry or an incoming HFP connection re-appends the same still-linked list node, turning session->reqs into a self-referential list that the host's list walkers never leave. The result is a fault or an unrecoverable hang in the Bluetooth host thread; the stray indirect call is through an all-zero pointer whose target the attacker does not control, so the practical impact is denial of service.

The fix keeps the object allocated and marks it with a new BT_HFP_HF_FLAG_RELEASING flag, letting bt_hfp_hf_discover_cb() release it once the discovery completes instead of destroying it under the SDP client. Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_HFP_HF enabled are affected.
Published: 2026-10-26
Score: 5.3 Medium
EPSS: n/a
KEV: No
Impact: Denial of Service
Action: Apply Patch
AI Analysis

Impact

A use‑after‑free vulnerability occurs when a Bluetooth HFP Hands‑Free object is wiped while an SDP discovery is still pending. The wipe zeroes internal structures that are still referenced by the SDP client, leading to null pointer dereferences and a crash or hang in the Bluetooth host thread. The affected weakness is a classic use‑after‑free error (CWE-416). The practical result is a denial of service of the Bluetooth subsystem, potentially rendering the host unresponsive during an HFP connection attempt.

Affected Systems

The vulnerability is present in the Zephyr OS Bluetooth Classic stack for configurations that enable CONFIG_BT_CLASSIC and CONFIG_BT_HFP_HF. No specific product version list is supplied, so any Zephyr build containing those options is affected until the patch is applied.

Risk and Exploitability

The CVSS score of 5.3 indicates moderate severity. No EPSS score is available, and the vulnerability is not listed in the CISA KEV catalog. The most likely attack path is a remote Bluetooth Classic device advertising an HFP Audio Gateway with an RFCOMM channel number outside the valid 1‑30 range; this will cause the local host to fail the RFCOMM connection, trigger the unsafe wipe, and ultimately crash the host. Because the fault involves dereferencing a zeroed pointer that the attacker cannot control, a successful exploitation results in a denial of service but not in arbitrary code execution.

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

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the Zephyr patch that preserves the HFP Hands‑Free object until discovery completes (refer to commit 6119da5d632594131304dec85000a75dc17743d2 or later releases).
  • If the HFP functionality is not required, disable CONFIG_BT_CLASSIC or CONFIG_BT_HFP_HF in your build configuration to eliminate the vulnerable code path.
  • As an interim defensive measure, add validation in your application or in the Bluetooth stack to ensure any RFCOMM channel passed to bt_hfp_hf_connect is within the 1‑30 range before initiating the connection.

Generated by OpenCVE AI on October 26, 2026 at 17:37 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 bt_hfp_hf_connect() in subsys/bluetooth/host/classic/hfp_hf.c allocates the per-connection HFP Hands-Free object with hfp_hf_create(), which starts an SDP discovery by passing the object's embedded hf->sdp_param to bt_sdp_discover(). That call links the caller-owned parameter block into the SDP client's request list (session->reqs in subsys/bluetooth/host/classic/sdp.c). If the subsequent bt_rfcomm_dlc_connect() then failed, the affected code wiped the entire object with (void)memset(new_hf, 0, sizeof(*new_hf)) while that discovery was still outstanding, zeroing the sys_snode_t _node that is still linked in the SDP client's list along with the request's func, uuid and pool pointers, and zeroing the hf->slc_work work item that may already be queued on the system workqueue. The discovery could not be retracted instead: bt_sdp_discover_cancel() is declared in include/zephyr/bluetooth/classic/sdp.h but has no implementation. The failing branch is reachable with peer-supplied input. The documented use of bt_hfp_hf_connect() is to pass the RFCOMM channel read out of the remote Audio Gateway's SDP record; neither bt_sdp_get_proto_param() nor bt_hfp_hf_connect() range-checks that value, so a remote device advertising an HFP AG record with an RFCOMM channel outside 1-30 makes bt_rfcomm_dlc_connect() return -EINVAL and drives the local device into the wipe. The same branch is reached without any application misuse when the remote peer controls connection timing, for example when the RFCOMM session is in BT_RFCOMM_STATE_DISCONNECTING or the ACL is dropped between object creation and the RFCOMM call. Once the object has been wiped, the Bluetooth host continues to use it: sdp_client_alloc_buf() dereferences session->param->pool, which is now NULL, and the SDP receive paths call session->param->func() through a null function pointer, neither of which is NULL-checked. Because the wipe also clears hf->acl, the pool slot is considered free and a retry or an incoming HFP connection re-appends the same still-linked list node, turning session->reqs into a self-referential list that the host's list walkers never leave. The result is a fault or an unrecoverable hang in the Bluetooth host thread; the stray indirect call is through an all-zero pointer whose target the attacker does not control, so the practical impact is denial of service. The fix keeps the object allocated and marks it with a new BT_HFP_HF_FLAG_RELEASING flag, letting bt_hfp_hf_discover_cb() release it once the discovery completes instead of destroying it under the SDP client. Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_HFP_HF enabled are affected.
Title Use of a released HFP HF object after a failed RFCOMM connect in the Bluetooth Classic host
Weaknesses CWE-416
References
Metrics cvssV3_1

{'score': 5.3, 'vector': 'CVSS:3.1/AV:A/AC:H/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.831Z

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

Link: CVE-2026-82388

cve-icon Vulnrichment

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

cve-icon NVD

Status : Awaiting Analysis

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

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

Link: CVE-2026-82388

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

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

Weaknesses