Zephyr RTOS EUVD-2026-109974

Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_HFP_HF enabled are affected, on Zephyr 4.4.0 through 4.4.2, with the device acting as an HFP Hands-Free unit. The attacker must be within Bluetooth (Adjacent) range and act as a remote Audio Gateway. The failure branch is driven either by advertising an HFP AG SDP record whose RFCOMM channel is outside 1-30 (bt_sdp_get_proto_param() and bt_hfp_hf_connect() perform no range check, so bt_rfcomm_dlc_connect() returns -EINVAL), or by controlling connection timing so the RFCOMM session is in BT_RFCOMM_STATE_DISCONNECTING or the ACL is dropped between object creation and the RFCOMM call. A key LIMITING factor: exploitation requires application code that passes the peer-discovered RFCOMM channel into bt_hfp_hf_connect() - the only in-tree caller is the shell sample and no in-tree sample does this, so reachability depends on vulnerable product application code rather than any default Zephyr build.

This is a medium-severity, denial-of-service-only flaw (CVSS 5.3, CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) whose signals point to a real but low-urgency issue rather than an emergency. Impact is limited to availability (A:H) - a fault or unrecoverable hang in the Bluetooth host thread; the stray indirect call goes through an all-zero pointer the attacker does not control, so there is no code-execution or data-exposure path (C:N/I:N). The attack vector is Adjacent (AV:A): the attacker must be within Bluetooth range and acting as, or impersonating, a remote HFP Audio Gateway. There is no CISA KEV listing and no public exploit or PoC reference in the input, so exploitation status is 'no public exploit identified at time of analysis'. No EPSS score was provided, so probabilistic exploitation likelihood cannot be weighed; this gap should be noted rather than assumed low. The vuln.today decision label is 'this_month' (not act_now/emergency), consistent with a patch-on-normal-cadence priority. A significant mitigating factor from the vendor's own evidence: the only in-tree caller of bt_hfp_hf_connect() is a shell sample, and no in-tree sample feeds a discovered RFCOMM channel, so reachability is limited to product application code that passes the peer-supplied channel without validation. PR:N honestly reflects that no local authentication is required, but real-world exposure depends on both the niche build configuration (CONFIG_BT_CLASSIC + CONFIG_BT_HFP_HF) and the presence of vulnerable application code.

A remote Bluetooth device within range advertises an HFP Audio Gateway SDP record containing an RFCOMM channel outside the valid 1-30 range; when the Zephyr Hands-Free device reads that channel and calls bt_hfp_hf_connect(), bt_rfcomm_dlc_connect() returns -EINVAL and the pre-fix failure branch memset-wipes a still-live HFP object whose SDP discovery request remains linked in the SDP client's list. Subsequent SDP processing then dereferences a now-NULL pool pointer or calls through a NULL func pointer, faulting the Bluetooth host thread, or re-linking the zeroed node produces a self-referential list that hangs the host's list walkers. No public exploit code is identified; the same outcome is also reachable without a malformed channel when the peer controls connection timing.