Zephyr EUVD-2026-109975

Only Zephyr builds with CONFIG_BT_CLASSIC and CONFIG_BT_HFP_AG operating in the Audio Gateway role are affected - this is a non-default configuration. Exploitation requires a BR/EDR device within Bluetooth radio range whose SDP Hands-Free service record advertises an RFCOMM channel outside the valid 0x01..0x1e range (deterministically forcing bt_rfcomm_dlc_connect() to return -EINVAL), or alternatively the peer dropping the ACL or racing an RFCOMM DLC on the same DLCI to time a connect failure. Reading the peer SDP record requires no pairing (unauthenticated, PR:N). Limiting factors: the attacker must be in adjacent Bluetooth proximity (AV:A), the target must be built as an HFP Audio Gateway, and impact is confined to crash/hang of the Bluetooth stack (availability only).

This is a genuine but bounded availability issue, best treated as a medium-priority patch item rather than an emergency. The CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 6.5) aligns well with the described mechanism: a BR/EDR attacker within Bluetooth radio range can reach the bug without pairing (PR:N) and trigger it deterministically by advertising an out-of-range RFCOMM channel (AC:L), with impact limited strictly to availability (C:N/I:N/A:H) - the advisory is explicit that the write is a constant zero at a fixed static address, so there is no attacker-controlled write and no memory-corruption/RCE path. The vuln.today decision label is 'this_month', consistent with a remotely-reachable DoS that is not under active exploitation. No EPSS score, no CISA KEV listing, and no public exploit were provided (the only references are the vendor patch commit and the GHSA advisory), so exploitation is 'no public exploit identified at time of analysis'. Two factors raise, rather than lower, the practical concern: the trigger is deterministic and requires no pairing, and the GHSA explicitly marks the fix as INCOMPLETE - the patch only defers release on the bt_hfp_ag_connect() initiator failure path, while the incoming-connection path (hfp_ag_disconnected() clearing acl_conn and hfp_ag_create() reached from hfp_ag_accept()) can still wipe an AG object with a linked SDP request, reproducing the same NULL-deref/hang class (open on main as of c4aa9324508). Net: real and worth patching this cycle for affected AG builds, but confined to adjacent-range DoS of the Bluetooth stack, and applying the current patch does not fully close the vulnerability.

A malicious BR/EDR device within Bluetooth radio range of a Zephyr Audio Gateway advertises a Hands-Free SDP service record containing an RFCOMM channel outside the valid 0x01..0x1e range; reading this record requires no pairing. When the AG reads the record and attempts the RFCOMM connect, bt_rfcomm_dlc_connect() fails, the AG object is memset() while its SDP request node is still linked, and the next SDP list advance dereferences the zeroed pool/func pointers - crashing or hanging the Bluetooth stack. No public exploit code was identified; the attacker can alternatively force the failure by dropping the ACL or racing an RFCOMM DLC on the same DLCI.